设计模式复习笔记(策略模式)

类别:软件工程 点击:0 评论:0 推荐:

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

本文地址:http://com.8s8s.com/it/it33604.htm