作者：未知 来源：月光软件站 加入时间：2005-2-28　月光软件站

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的数据。

相关软件：