Strategy（策略）模式
Intent
定义一族算法，分别封装起来，让它们可以互换。策略模式把算法与使用算法的Client之间的关系相对独立。
Also Known As
Policy
Motivation
有很多算法都可以实现将一个文本流按行拆分(以下建成分行)的功能。把这些算法写死在用到这些算法的类里是不必要的，原因如下：
1． 会使需要分行的Client变得臃肿，难以维护，特别是在需要支持多种分行算法的情况下。
2． 不同的时候会用到不同的算法。我们不希望支持那些我们用不到的算法。
3． 如果分行算法成为Client的一部分，那么添加新的不同于已有的算法就会变得十分困难。
我们可以通过定义封装不同分行算法的类的方式来避免上述问题。通过这种方式封装的一个算法称为一个策略。
假设Composition 类负责维护和更新分行文本在文本查看器中的显示。分行策略不是由Composition类来实现，而是分别由抽象的Compositor类的子类们来实现。 Compositor 的子类们实现了不同的策略。
SimpleCompositor 实现了一个简单的策略。一行一行地分。
TeXCompositor 实现了发现分行的TeX算法。这个策略试图站在全局的角度来优化分行的算法。一个段落一个段落地分。
ArrayCompositor 实现了一个策略，选择分行，这样每一行都有固定数目的项。例如，在将一组图表分成行的时候这个策略就很有用。
一个Composition对象维护了一个Compositor 对象的引用。任何时候当Composition对象需要重排文本的时候，就会将这个工作转交给它的Compositor 对象去处理。应该使用哪一个 Compositor对象是由Composition对象的Client 指定和安装的。
Applicability
以下情况下可以考虑使用策略模式：
1． 有很多相关的类，仅仅是行为有所不同。策略模式提供了一个对一个类进行配置，使之能够拥有多种行为的方法。
2． 你需要不同的可变的算法。例如，你可以定义反映不同的时间/空间开销的算法。如果这些不同的算法使用继承的形式实现的话，就可以使用策略模式。
3． Client不需要了解一个策略具体使用的数据。策略模式可以避免暴露复杂的，算法特定的数据结构。
Structure
Participants
Strategy (Compositor)
宣告了一个对所有支持算法都共通的接口。Context 使用这个接口来掉用ConcreteStrategy.定义的算法。
ConcreteStrategy (SimpleCompositor, TeXCompositor, ArrayCompositor)
实现了Strategy接口的算法。
Context (Composition)
由ConcreteStrategy 对象来配置。
维护一个Strategy 对象的引用.
可以定义一个接口让Strategy 对象访问Context的数据。
