《Head First 设计模式》之策略（一）

从模拟鸭子应用做起

Joe准备做一套成功的模拟鸭子游戏。游戏中会出现各种鸭子，一边游泳戏水，一边呱

呱叫。

设计了一个鸭子超类（SuPerClass)，并让各种鸭子继承此超类。

 

 

现在想让鸭子能飞

 

可怕问题发生了

Joe忽略了一件事，并非Duck所有的子类都会飞。

 

我们能做的，只有根据鸭子的特性，覆写fly()方法才可以，该fly()或者实现一定功能或者什么事都不做。

 

在超类中加上fly()，就会导致所有的子类都具备fly()，连那些不具备fly()的子类也无法免除。所以，当涉及“维护”时，为了“复用”（reuse）目的而使用继承，结果可能会很糟。

 

因为这样做（利用继承来提供Duck的行为），带来的不好的地方：

1. 代码在多个子类中重复。

2. 运行时的行为不容易改变。

3. 不能直接看出该鸭子都有哪些行为（虽然有fly()方法，但里面什么事都没做）

4. 改变会牵一发动全身，造成其他鸭子不想要的改变。

 

利用接口如何

把fly()从超类中取出来，放进一个“flyable接口”中，只有会飞的鸭子才实现此接口。同样的方式来设计“Quackable接口”，因为不是所有的鸭子都会叫。

想想这样如何？

……

虽然Flyable和Quackable可以解决“一部分”问题（不会再有会飞的橡皮鸭），但却造成代码无法复用，依然不够好。

 

变是永远不变的

不管你在何处工作，构建些什么，用何种编程语言，在软件开发上，一直伴随你的那个不变真

理是？

不管当初软件设计得多好，一段时间之后，总是需要成长与改变

否则软件就会“死亡”。

 

封装变化，从零开始

设计原则：找出应用中可能需要变化之处，把他们独立出来，不要和那些不需要变化的代码混在一起。

把变化的部分取出并封装起来，以便以后可以轻易地改动和扩充此部分，而不影响不需要变化的部分。

分开变化和不会变化的部分   

    你能想象出如何设计吗？？？