设计模式十四式 : 策略模式 - 从做鸭开始。

OO基础：
抽象
封装
多态
继承

OO原则：
封装变化
多用组合，少用继承
针对接口编程，不针对实现编程

OO模式：
策略模式 定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。

1. 如果我们做一个鸭子游戏，这个游戏里面有各种各样的鸭子。通常先对鸭子这个群体进行抽象，设计一个超类 Duck，这个超类中定义了所有鸭子们都会有的行为方法。然后其它形形色色的鸭子子类继承超类Duck。
   如下图1
   

2. 继承的好处是代码复用。缺点是牵一发而动全身。如果改动了父类，那么所有子类都会跟着发生改变。父类新添加的行为在某些子类中也许是不需要的，甚至是BUG一样的存在。还有就是代码在多个子类中重复，比如对于黄橡皮鸭，绿橡皮鸭，蓝橡皮鸭它们的叫声函数内的代码都一样：“吱吱吱…”（当然也可以用多层继承，做一个橡皮鸭的二级父类。来解决橡皮鸭叫声行为不能复用的问题，但是这样也会引入另一个问题类树结构复杂，难以维护）。
   如下图2
   

3. 尝试用接口的办法，以解决继承所带来的牵一发而动全身的问题。只让每个鸭子子类实现它所拥有的特定行为接口。通过接口把鸭子的行为这一变化从鸭子身上剥离出来，进行了封装，组合，避免了牵一发而动全身。但这样似乎也失去了继承的复用优势，同上2中代码在多个子类中重复的问题依然存在，每当我们要改变某一类行为时，就需要深入到每个子类中去修改这一类方法。这个问题本质上是因为我们是针对实现编程的，鸭子的行为都在每个鸭子的子类中实现，行为的具体实现和鸭子是绑死的。
   如下图3
   

4. 针对接口编程，而不是针对实现编程。把鸭子的行为也抽象为类，然后将鸭子类和行为类进行组合。多用组合少用继承。有一个可能比是一个更好。
   仔细看下图4
   PS: 这是小弟的个人读书笔记，目的是记录反刍。文中可能会有理解错误，阐述不明的地方。如有请批评指正，不胜感激。