浅尝设计模式——如何使用策略模式

本文为阅读《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使用到了策略模式。