java 设计模式 学习小结1

从一个模拟鸭子（SimuDuck）的游戏开始我们的模式入门：
设计一套模拟鸭子的应用程序，可以让模拟的鸭子表现出各种各样的行为。起初根据实际情况设计出来的类图是：




图1
注：实线带一个三角箭头为继承，虚线带一个三角箭头为实现
几天后客户突然提出了新的要求，客户要让鸭子飞起来，以表现自己的竞争力，于是我们在超类Duck中加入了fly（）方法，以使子类具有飞行的方法。
问题出来了：
Question1：这样继承导致某些不具有飞行行为的子类也具有了飞行行为，这是很可怕的。
Question2：以后需求还会不断变化，这样超类的修改会很频繁，直接导致的后果是，子类的维护会出现很大的困难，即我们所说的类爆炸。
提示1：在涉及到维护时，为了复用项目而使用继承，并不完美
利用继承来提供鸭子的行为，会导致下列的缺点：
1：代码在多个子类中的重复2：运行时的行为不容易改变3：很难知道所有鸭子的行为4：改变会造成不需要改变的部分也改变了
在继承不能解决问题的情况下，我们进一步提出了通过实现接口来改变这种状态，类图如下：
图2



这样可以使得只有那些会飞的鸭子采取实现飞行接口，但是又产生了另一个问题：代码的复用问题。（接口不具有实现代码，所以继承接口无法达到代码的复用）
设计原则1：找出应用中可能需要变化的部分，把他们独立出来，不要和那些不需要变化的代码混在一起。
结果会是：代码变化引起的不经意后果减少，系统变的会有弹性。
设计原则2：针对接口编程，而不是针对实现编程；（针对接口编程是针对超类型编程，，多态起到了关键作用。好好琢磨，）
无论是继承自超类的行为，还是子类自己实现的行为，都是针对实现编程，这样，我们的行为会被固定成一个模式，很难有变化。现在假如我们定义了两个接口一个是飞行接口（FlyBehavior）和叫的接口（QuackBehavior），然后定义具体的实现类（行为子类）去实现这两个接口，这样，子类在实现行为时会继承这些行为类的方法，既达到了代码的复用，也达到了系统有弹性，以后要增加实际子类时，只要根据子类的行为动态的去更改行为子类就可以了。
针对几口编程举例：现在又两个类Dog和Animal，Dog继承自Animal，
针对实现编程：Dog d = new Dog();
d.bark();
针对接口编程：Animal animal = new Dog();
Animal.makeSound();
程序类图的初步整合：
图3


在最后整合的类图中我们可以看到，超类Duck类并没有做很大的变化，只是将叫的行为和飞的行为分离出来，他们是由一系列实现了飞行接口和叫的接口的行为类组成的，这样既实现了继承带来的代码复用，又避免了继承所带来的沉重包袱。
最终的程序类图组合为：
图4




每一个Duck有一个飞行接口和叫的接口，将飞行和瓜瓜叫委托给他们代为处理。
这时鸭子的行为不是从超类继承过来的，而是和适当的行为对象组合而来的，系统弹性很大。
至此，我们的模拟鸭子程序就初步完成了，当然模式是一种经验的结合，他不是绝对的，不同的场合可以用到不同的模式甚至是不同模式的组合，这是随着开发人员的经验而设计的。
我们将模拟鸭子所用到的模式定义为：策略模式
定义一些算法族，将他们封装起来，让他们可以互相替换，使得算法的变换独立于使用算法的客户。
模式要点：
1：知道oo基础，并不足以让你设计出良好的oo系统，即可维护、可扩展、弹性大。
2：模式不只是一个名称，它代表的是一整套模式背后所象征的质量、特性和约束。
3：模式不是代码，而是解决一系列问题的通用方案。
4：大多的模式都遵循局部改变独立于系统的其他部分。
5：模式将变化的部分和不变化的部分分离出来。