策略 - 鸭子的不同行为

抽象的鸭子，有几个子鸭子类继承了
来了个变态需求：我们要鸭子会飞(本人见过)

比较好想的解决方法是：在抽象鸭子中加个fly方法
解决了，生活真美好,感谢继承感谢cctv

有看官说了:等等，我家儿子的橡胶玩具鸭子也继承了你那个类了，它不会飞啊
...... 呃，在你的玩具鸭子上覆写fly方法就好了嘛，表烦我

我们家还有诱饵鸭子，不飞也不叫，木头的

...... 你家鸭子真BT

教训：在超类上加上新的行为，会使某些不适合该行为的子类也具有该行为

看来维护的时候，为了reuse而使用的继承，还真有点问题

 

大师原则：针对接口编程

好的，我把fly从抽象鸭子里提出来放在个接口里，想飞的鸭子去实现吧 

但是，太多的鸭子类可能要写相同的fly方法，代码太多了吧，呃。。。好像还不如继承来的方便

 

大师原则：多用组合，少用继承

is-a和has-a，不继承的话，我们就has-a吧

OK，接口仍然存在，想飞的鸭子类可以持有该接口做为一个属性，并且委托接口的不同实现去fly

不管你是想用翅膀飞，还是想坐飞机飞，还是火箭动力飞，只要把不同的实现插接到鸭子上，

而鸭子代码不用做任何改变就可以随便怎么飞，这就是抽象的好处

 

大师原则：封装变化

呃。。。。那不用继承，抽象鸭子类也应该做成接口吗？

我们处理的变化的部分，固定不变的部分，让它们被继承好了，我们甚至可以把被继承的类做成具体类。

我们不可能预料到所有的变化，如果出现了新了变化，做上面同样的处理就是了。

目前，我们解决了原先变化的问题，这样就可以了，要有个度，没有必要全部来抽象，会提高不必要的复杂度。 

关键：处理变化的部分

 

而飞的行为被抽出来，跟鸭子没有什么关系。

老母鸡也想飞？OK，用飞的接口声明个属性去，我这里有翅膀火箭喷气等等各种飞，拿去插到你的类中

 

面向对象向我们承诺了“复用”，有很多方法，但继承是种强耦合，所以我们用组合

 

OO强烈追求的目标是：解耦，把会变化的部分抽出并封装起来，

以期让系统中某部分的改变不影响到其它部分，几乎每个模式都体现出这种精神，并提供一种方式来实现此目标。

 

这里，我们得到了“策略”模式

正式定义是：策略模式定义了算法族，分别封装起来，让它们之间可以互相替换，

此模式让算法的变化独立于使用算法的客户

 

ps:这是我最喜欢的模式