本文为阅读《Head First 设计模式》一书的摘要总结
策略模式
概念
策略模式定义了 算法族(一组行为),分别封装起来,让他们之间可以相互替换,此模式让算法的变化 独立于 使用算法的客户。
Demo
现在我们要加入一个橡皮鸭RubberDuck
,若是直接继承Duck
类,那么RubberDuck
将具有同其他两个类相同的fly
和quack
的行为,但事实上RubberDuck
不应该有这两个行为。
-
一个解决办法就是在
RubberDuck
中覆盖fly
方法,方法体中不做任何操作。但如果以后还会加入一些不应该具有fly
或quack
行为的类,使用继承似乎就不太合理了,因为这违背了使用继承来提高代码复用的原则。 -
另一个解决方法就是将
fly
和quack
行为抽象为接口:
但是这又导致了代码 无法复用。
- 我们使用以下设计原则,来重构代码
设计原则1:找出应用中可能需要变化之处,把它们独立出来,不要和那些不需要变换的代码混在一起
fly
和quack
两个方法是需要变化的,我们把它们独立出来,并抽象出FlyBehavior
和QuackBehavior
两个接口,具体的行为由它们的实现来完成。
这样的设计,fly
和quack
两个行为已经独立于Duck
类二可以被其它任何需要这些行为的类使用了,这不仅消除了继承带来的一些弊端,还进一步提高了代码的复用。
设计原则2:针对接口编程,而不是针对实现编程
我们在Duck
类中加入两个实例域,分别为flyBehavior
和quackBehavior
。声明为接口类型,每个Duck
对象都可以 动态的 在运行时引用正确的类型。fly
和quack
行为被委托给FlyBehavior
和QuackBehavior
具体实现去完成。
设计原则3:多用组合,少用继承
我们为实例域flyBehavior
和quackBehavior
添加setter方法,使Duck
可以动态的设定行为:
当我们动态的设定flyBehavior
和quackBehavior
的引用,将两个对象结合起来使用时,这就是 组合 。使用组合建立系统具有很大的弹性,不仅可以将算法族封装成类,还可以“在运行时动态地改变行为”。
至此这个Demo的类图如下:
我们将fly和quack两个行为(算法族)独立出来,分别封装成FlyBehavior
和QuackBehavior
两个接口的实现,这连个行为已经独立于Duck
类(算法的使用客户)了。并且我们还在Duck
类中定义了行为修改器,可以替换行为的不同实现方式。因此,上面的Demo使用到了策略模式。