STRATEGY(策略)一对象行为型模式 来自《设计模式：可复用面向对象软件的基础》总结

1.STRATEGY模式的意图

定义一系列的算法，把它们一个个封装起来,并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。
举个例子：
使用螺丝刀的时候，针对不同的工作任务，选取不同的“刀头”，但目的并非将
螺丝刀与刀头组合起来建立永久的delegation，而只是临时通过delegation完成任务（即调用刀头的“算法”），然后二者再无联系。
所以说STRATEGY模式强调算法的动态调用，但前提是动态绑定

2.我们为什么需要STRATEGY模式

有许多算法可对一个正文流进行分行。将这些算法硬编进使用它们的类中是不可取的，其原因如下:

• 需要换行功能的客户程序如果直接包含换行算法代码的话将会变得复杂，这使得客户程序庞大并且难以维护，尤其当其需要支持多种换行算法时问题会更加严重。
• 不同的时候需要不同的算法，我们不想支持我们并不使用的换行算法。
• 当换行功能是客户程序的一个难以分割的成分时,增加新的换行算法或改变现有算法将.十分困难。

3.一个STRATEGY模式的例子

假设一个情况：我们需要设计一款文字处理软件，软件中需要设计排版的算法，而对于不同的文本，排版的方法也不通。
因此我们可以定义一些类来封装不同的换行算法，从而避免这些问题。一个以这种方法封装的算法称为一个策略(strategy),如下图所示。

●Strategy(策略，如Compositor)

• 定义所有支持的算法的公共接口。Context使用这个接口来调用某个ConcreteStrategy定义的算法。

●ConcreteStrategy(具体策略，如SimpleCompositor, TeXCompositor, ArrayCompositor)

• 以Strategy接口实现某具体算法。

●Context(上下文，如Composition)

• 用一个ConcreteStrategy对 象来配置。
• 维护一个对Strategy对象的引用 。
• 可定 义一个接口来让Stategy访问它的数据。

---

类之间的协作
● Strategy和Context相互作用以实现选定的算法。当算法被调用时，Context可以将该算法所需要的所有数据都传递给该Stategy。或者，Context可 以将自身作为一个参数传递给Strategy操作。这就让Strategy在需要时可以回调Context。

● Context将它的客户的请求转发给它的Strategy。客户通常创建并传递一个ConcreteStrategy对象给该Context;这样,客户仅与Context交互。通常有一系列的ConcreteStrategy类可供客户从中选择。

---

STRATEGY(策略)对象行为型模式优点与缺点：

优点：

• 提高了代码的扩展性与复用性，且不会违背ocp原则
• 策略之间可以互相替换，类可以根据需求选择合适的策略。
• 可以避免多重条件选择语句如switch和if-else，提高了代码的可读性。
• 调用算法的类无需永久保存被调用算法所在的类后者的实例。

缺点：

• 客户端不能使用同时多个策略类，无法满足一个类需要两个策略先后处理的案例
• 如果我们对策略有修改的需求的话，可能就需要创建一个新的策略
• 客户必须了解不同的Strategy本模式有一个潜在的缺点， 就是一个客户要选择一个合适的Strategy就必须知道这些Strategy到底有何不同。此时可能不得不向客户暴露具体的实现问题
• 客户端必须支付Strategy和Context之间的通信开销。需要在Strategy和Context之间更进行紧密的耦合。