Strategy(策略)---对象行为型模式

定义一系列的算法,把它们一个个封装起来,并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。

当存在以下情况时使用Strategy模式:

1、许多相关的类仅仅是行为有异。“策略”提供了一种用多个行为中的一个行为来配置一个类的方法。

2、算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构。

3、一个类定义了多种行为,并且这些行为在这个类的操作中以多个条件语句的形式出现。将相关的条件分支移入它们各自的Strategy类中以代替这些条件语句。

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

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

Strategy模式有下面的优点和缺点:

1、Strategy类层次为Context定义了一系列的可供重用的算法或行为。继承有助于析取出这些算法中的公共功能。

2、继承提供了另一种支持多种算法或行为的方法。你可以直接诶生成一个Context类的子类,从而给它以不同的行为。但这会将行为硬行编制到Context中,而将算法的实现与Context的实现混合起来,从而使Context难以理解、难以维护和难以扩展,而且还不能动态地改变算法。最后你得到一堆相关的类,它们之间的唯一差别是它们所使用的算法或行为。将算法封装在独立的Strategy类中使得你可以独立于其Context改变它,使它易于切换、易于理解、易于扩展。

3、Strategy模式提供了用条件语句选择所需的行为以外的另一种选择。当不同的行为堆砌在一个类中时,很难避免使用条件语句来选择合适的行为。将行为封装在一个个独立的Strategy类中消除了这些条件语句。

含有许多条件语句的代码通常意味着需要使用Strategy模式。

4、Strategy模式可以提供相同行为的不同实现。客户可以根据不同时间、空间权衡取舍要求从不同策略中进行选择。

5、客户必须了解不同的Strategy。Strategy模式有一个潜在的缺点,就是一个客户要选择一个合适的Strategy就必须知道这些Strategy到底有何不同。此时,可能不得不向客户暴露具体的实现问题。

6、Strategy和Context之间的通信开销。无论各个ConcreteStrategy实现的算法是简单还是复杂,它们都共享Strategy定义的接口。因此很可能某些ConcreteStrategy不会都用到所有通过这个接口传递给它们的信息。简单的ConcreteStrategy可能不使用其中的任何信息。这就意味着有时Context会创建和初始化一些永远不会用到的参数。如果存在这样问题,那么将需要在Strategy和Context之间更尽兴紧密的耦合。

7、Strategy模式增加了一个应用中的对象的数目。有时你可以将Strategy实现为可供各Contxt共享的无状态的对象来减少这一开销。任何其余的状态都由Context维护。Context在每一次对Strategy对象的请求中都将这个状态传递过去。共享的Strategy不应在各次调用之间维护状态。Flyweight模式更详细地描述了这一方法。

考虑下面的实现问题:

1、定义Strategy和Context接口。Strategy和Context接口必须使得ConcreteStrategy能够有效地访问它所需要的Context中的任何数据,反之亦然。一种办法是让Context将数据放在参数中传递给Strategy操作。也就是说,将数据发送给Strategy。这使得Strategy和Context解耦。但另一方面,Context可能发送一些Strategy不需要的数据。

另一种办法是让Context将自身作为一个参数传递给Strategy,该Strategy再显式地向该Context请求数据。或者,Strategy可以存储对它的Context的一个引用,这样根本不再需要传递任何东西。这两种情况下,Strategy都可以请求到它所需要的数据。但现在Context必须对它的数据定义一个更为精细的接口,这将Strategy和Context更紧密地耦合在一起。

2、使Strategy对象成为可选的。如果即使在不使用额外的Strategy对象的情况下,Context也还有意义的话,那么它还可以被简化。Context在访问Strategy前先检查它是否存在,如果有,那么就使用它。如果没有,那么Context执行缺省的行为。这种方法的好处是客户根本不需要处理Strategy对象,除非它们不喜欢缺省的行为。

Flyweight模式:Strategy对象经常是很好的轻量级对象。

猜你喜欢

转载自linshiquan.iteye.com/blog/1070115