《Head First设计模式》读书笔记_第一章
策略模式
例:设计一个模拟鸭子游戏,游戏中有各种鸭子,一边戏水一边嘎嘎叫。
所以学习设计模式前,我们最先想到的就是设置一个超类,并让其他子类去继承这个类,UML图如下:
*
*
但是,程序需求是会经常变动的,若给游戏中加入飞行方法以及玩具小黄鸭呢?并不是所有鸭子都可以飞,也并不是所有鸭子都是嘎嘎叫。
此时你可能会想,在父类添加相应方法,在子类重写就可以让不同鸭子的同一方法具有不同表现了!
然而当子类数量剧增时你都要到对应子类去逐个修改,这将是个复杂又无聊的工作!单独使用接口也同样会使代码量变多,出现许多重复性代码。
那么,还有其他更好的方式来添加飞行方法吗?
有,就是委托。我们可以把委托者和被委托者想成has-a(有一个)的关系。比如上面这个例子,鸭子(被委托者)有一个飞行行为(委托者)
把飞行想成Duck的一个功能,Duck具有该功能,即Duck本身含有飞行行为的实例,可以调用飞行行为的飞行方法。
找出易于变化的部分,把他们独立起来
把会变化的部分取出封装起来,好让其他部分不会受到影响。代码变化引起的不经意后果变少,系统将变得更有弹性。
针对接口编程,而不是针对实现编程
将会变化的部分放在类中,此类专门提供某行为接口的实现,这样主类就不需要知道行为的实现细节。
多用组合,少用继承
相应的UML图
实际代码
设计两个接口类让所有飞行类及所有叫声类都实现对应的接口
接口 FlyBehavior
1 2 3 |
|
接口QuackBehavior
1 2 3 |
|
这样设计接口让飞行与叫声的动作可以被其他对象复用又可以新增一些行为类而不会影响既有的行为类,也不会影响到“使用”行为的类。
编写对应的类实现接口,让这些类负责实现具体的行为。
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
在此省略其他行为类的展示...
在Duck类中怎加两个实例变量,声明为我们刚刚建立的接口类型,这样Duck都能在运行时动态地设置这些变量并保证引用正确的行为类型。
Duck类:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
|
MallardDuck类:
1 2 3 4 5 6 7 8 9 10 11 |
|
MiniDuckSimulator类:
1 2 3 4 5 6 7 8 9 10 11 12 |
|
动态设定行为
模型鸭既不会飞也不会叫,但我们在Duck类中添加了seter方法以便动态设定行为,给模型鸭添加一个火箭助推器,让它飞起来。
ModelDuck类
1 2 3 4 5 6 7 8 9 10 11 |
|
对MiniDuckSimulator类稍作改动,
1 2 3 4 5 6 7 8 9 |
|
输出将是:
1 2 |
|
总结
策略模式的三项原则:
1、找出应用中可能需要变化之处,把它们独立出来,不要和那些无需变化的代码混在一起。
2、针对接口编程,而不是针对实现编程
3、多用组合,少用继承
分离变与不变。回忆之前的需求,可以发现,不变的是swim,变的是fly与quack。虽然swim和fly都是鸭子的行为,但是swim不怎么变化,它可以利用继承来实现代码复用,而飞行方式却有很多种,无法继承,因此需要将飞行行为抽出来,各自实现,让Duck实现类拥有飞行行为实例,达到操作飞行行为的目的。这种思想就像零件的组装,主体是不变的,零件有各种相同功能不同性能的各种款式,这样可以做出不同的产品。
另外策略模式还有一个好处是可以动态变化行为,比如木头鸭子原来是不会飞的,它用setFlyBehavior设置不会飞行,后来设计师给他装上了引擎翅膀,它可以再次通过setFlyBehavior在运行时动态变更飞行行为。
文章来源: fantianzuo.blog.csdn.net,作者:兔老大RabbitMQ,版权归原作者所有,如需转载,请联系作者。
原文链接:fantianzuo.blog.csdn.net/article/details/84553705
- 点赞
- 收藏
- 关注作者
评论(0)