个人总结：系列一：设计模式入门.docVIP

从一个模拟鸭子（SimuDuck）的游戏开始我们的模式入门： 设计一套模拟鸭子的应用程序，可以让模拟的鸭子表现出各种各样的行为。起初根据实际情况设计出来的类图是： 注：实线带一个三角箭头为继承，虚线带一个三角箭头为实现 几天后客户突然提出了新的要求，客户要让鸭子飞起来，以表现自己的竞争力，于是我们在超类Duck中加入了fly（）方法，以使子类具有飞行的方法。 问题出来了： Question1：这样继承导致某些不具有飞行行为的子类也具有了飞行行为，这是很可怕的。 Question2：以后需求还会不断变化，这样超类的修改会很频繁，直接导致的后果是，子类的维护会出现很大的困难，即我们所说的类爆炸。 提示1：在涉及到维护时，为了复用项目而使用继承，并不完美 利用继承来提供鸭子的行为，会导致下列的缺点： 1：代码在多个子类中的重复2：运行时的行为不容易改变3：很难知道所有鸭子的行为4：改变会造成不需要改变的部分也改变了 在继承不能解决问题的情况下，我们进一步提出了通过实现接口来改变这种状态，类图如下： 这样可以使得只有那些会飞的鸭子采取实现飞行接口，但是又产生了另一个问题：代码的复用问题。（接口不具有实现代码，所以继承接口无法达到代码的复用） 设计原则1：找出应用中可能需要变化的部分，把他们独立出来，不要和那些不需要变化的代码混在一起。 结果会是：代码变化引起的不经意后果减少，系统变的会有弹性。 设计原则2：针对接口编程，而不是针对实现编程；（针对接口编程是针对超类型编程，，多态起到了关键作用。好好琢磨，） 无论是继承自超类的行为，还是子类自己实现的行为，都是针对实现编程，这样，我们的行为会被固定成一个模式，很难有变化。现在假如我们定义了两个接口一个是飞行接口（FlyBehavior）和叫的接口（QuackBehavior），然后定义具体的实现类（行为子类）去实现这两个接口，这样，子类在实现行为时会继承这些行为类的方法，既达到了代码的复用，也达到了系统有弹性，以后要增加实际子类时，只要根据子类的行为动态的去更改行为子类就可以了。 针对几口编程举例：现在又两个类Dog和Animal，Dog继承自Animal， 针对实现编程：Dog d = new Dog(); d.bark(); 针对接口编程：Animal animal = new Dog(); Animal.makeSound(); 程序类图的初步整合： 在最后整合的类图中我们可以看到，超类Duck类并没有做很大的变化，只是将叫的行为和飞的行为分离出来，他们是由一系列实现了飞行接口和叫的接口的行为类组成的，这样既实现了继承带来的代码复用，又避免了继承所带来的沉重包袱。 最终的成粗类图组合为： 每一个Duck有一个飞行接口和叫的接口，将飞行和瓜瓜叫委托给他们代为处理。 这时鸭子的行为不是从超类继承过来的，而是和适当的行为对象组合而来的，系统弹性很大。 至此，我们的模拟鸭子程序就初步完成了，当然模式是一种经验的结合，他不是绝对的，不同的场合可以用到不同的模式甚至是不同模式的组合，这是随着开发人员的经验而设计的。 我们将模拟鸭子所用到的模式定义为：策略模式 定义一些算法族，将他们封装起来，让他们可以互相替换，使得算法的变换独立于使用算法的客户。 模式要点： 1：知道oo基础，并不足以让你设计出良好的oo系统，即可维护、可扩展、弹性大。 2：模式不只是一个名称，它代表的是一整套模式背后所象征的质量、特性和约束。 3：模式不是代码，而是解决一系列问题的通用方案。 4：大多的模式都遵循局部改变独立于系统的其他部分。 5：模式将变化的部分和不变化的部分分离出来。