一:策略模式

下面全是个人理解。


Head First 第一章中讲的策略模式,我觉得是所有设计 模式中最基本的。

它提到了几个设计原则:都是我们平常编程中用到的。

1:将应用中变化之处和,不需要变化之处分离出来。这其实就很类似,封装的定义;

2:面向接口编程,而不是面向实现编程。想想我们在做web项目时,servie层,以及dao层,都是面向接口编程的,为的就是如果换掉数据库实现,那么在action层,我们就不需要更改代码了。

3:少用继承,多用组合。我们在做web项目时,service实现中,包含有dao的引用 ,其实就是组合。而且这种组合是高内聚,低耦合的。因为我们可以在运行时,指定特定的dao实现。这也是一种面向接口编程。


Head First 第一章针对Duck(鸭子)类 做了一个探讨。

Duck 书中定义的是抽象类,它有quack() 呱呱叫的方法,以及swim() 游泳的方法,还有一个抽象方法display()  外观方法。每种鸭子,都继承Duck类,自己实现display方法。

需求1:现在在Duck中增加一个方法fly()方法,由于 使用的继承,那么所有实现了Duck的子类 ,都有fly方法,就是会飞。但是问题来了,由于使用的是继承,会导致有些 不会飞的鸭子也拥有这个方法,有的人说,会飞就会嘛,有什么 关系,但是 你自己不觉得很怪吗?还有人觉得,我让不会飞的鸭子重写fly()方法,让它什么 都不做不就可以了吗?咋一想,好像是这么一回事,但是,如果有这么 一种鸭子,不会飞也不会叫还不会游泳,那么 你完蛋了,这个时候,你要检查所有的子类了,看看它们的所有方法,是否满足条件了、

所以继承带来的问题就是,子类继承了不必要的一些行为。


这个时候,我想要了接口,把鸭子的每种行为定义成一个接口,让那么需要有这些行为的鸭子去实现它,就可以了。哎,仔细想想,好像可以。


需求2:假如有三个子类分别实现了Duck,按照上面的想法,定义一个fly方法,quack(),swim()。那么这三个子类,如果三个子类fly,swim,quack的实现都是一样,那么 这样 代码是不是重复写了很多呀!!现在只是三个子类,如果30个呢,想想。


需求3:讲到这里,Head First 讲到了最后的解决方案,其实也是用到了接口,只是和上面不一样,它是定义一组接口行为,只是它由一组专门实现接口行为的类来实现,而不是由鸭子类来实现,我们只需要在Duck类中定义一些鸭子类的行为,具体的实现,在运行时,自己定义。这样,即使再增加一些行为,也只需要在Duck类中定义这些行为,具体的实现,就不关鸭子的事情了。

你可能感兴趣的:(Head,First,设计模式)