学习headfirst设计模式小结,仅供学习讨论只用
从一个模拟鸭子(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:模式将变化的部分和不变化的部分分离出来。