例子:
一个游戏中有各种鸭子,红头鸭,绿头鸭等等,很自然得出这样的设计:
这时,需求改变了(永远不变的是改变).游戏需要鸭子能飞起来, 在抽象的Duck类中加入一个方法fly(),是一个很自然的想法.
但是,问题出现了,一些不能飞的鸭子(比如橡皮鸭)也飞了起来.——继承带来的问题:牵一发而动全身
我们可以找到一个暂时的办法:覆盖橡皮鸭的fly()方法,使这个方法什么也不做。然而随着鸭子的数量的增加,你必须检查每一个不会飞,或者不会叫的的鸭子的方法都被覆盖掉了,这个工作量将是巨大的。
此时,另一种设计方式似乎可行:让某些鸭子“可以飞”,“可以叫”——即实现Flyable接口,如图:
这样设计似乎概念上非常清楚,但是带来的问题显而易见:
1) 由于接口中没有方法的实现,不能复用代码,导致许多类中都有大量重复的代码
2) 如果需要修改所有类的quack()方法,需要对大量(比如说48个)子类进行修改
那怎么样设计才好呢?先看一下下面的设计原则:
1. 找出应用中可能变化指出,把他们独立出来,不要和那些不需要变化的代码混在一起。——把会变化的部分取出来并封装,好让其他部分不受影响。 2. 针对抽象(接口)编程,而不是针对实现编程.
在该场景中,可能变化的是鸭子的行为:即鸭子游泳的行为,鸣叫的行为,不同的鸭子不一样。所以根据原则1我们需要将鸭子的行为独立出来,并且将其抽象,我们只针对鸭子行为的抽象编程。按照这个思路,得出设计:
显然,这样的设计克服了上面几种设计的缺点,它既有继承的优点:重用代码,又克服了它的缺点:不会牵一发动全身,修改一个鸭子的行为,不会影响其他鸭子。它甚至可以在运行时动态的改变鸭子的行为。因为它采用的是组合,而不是继承。
这里得到另一个设计原则
多用组合,少用继承。
至此,我们可以得出策略模式的定义了:
策略模式定义了算法簇,分别封装起来,让他们之间可以相互替换,此模式让算法的变化独立于使用算法的客户