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

从一个模拟鸭子（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：模式不只是一个名称，它代表的是一整套模式背后所象征的质量、特性和