软件体系结构-7--1--2011-3.ppt

『策略模式』 定义了算法家族，分别封装起来，让它们之间可以互相替换， 此模式让算法的变化， 不会影响到使用算法的客户。 对象行为型模式 —STRATEGY(策略) 1.意图 定义一系列的算法,把它们一个个封装起来,并且使它们可相互替换。 本模式使得算法可独立于使用它的客户而变化。 2.别名 政策（Policy） 3.动机 有许多算法可对一个正文流进行分行。将这些算法硬编进使用它们的类中是不可取的，其原因如下: 需要换行功能的客户程序如果直接包含换行算法代码的话将会变得复杂，这使得客户程序庞大并且难以维护,尤其当其需要支持多种换行算法时问题会更加严重。 不同的时候需要不同的算法，我们不想支持我们并不使用的换行算法。 当换行功能是客户程序的一个难以分割的成分时,增加新的换行算法或改变现有算法将十分困难。 可以定义一些类来封装不同的换行算法，从而避免这些问题。一个以这种方法封装的算法称为一个策略(strategy)。 4.适用性 许多相关的类仅仅是行为有异。“策略”提供了一种用多个行为中的一个行为来配置一个类的方法。 需要使用一个算法的不同变体。例如，可能会定义一些反映不同的空间/时间权衡的算法。当这些变体实现为一个算法的类层次时,可以使用策略模式。 算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构。 一个类定义了多种行为,并且这些行为在这个类的操作中以多个条件语句的形式出现。将相关的条件分支移入它们各自的Strategy类中以代替这些条件语句。 5.结构 6.参与者 Strategy(策略，如Compositor) —定义所有支持的算法的公共接口。Context使用这个接口来调用某ConcreteStrategy定义的算法。 ConcreteStrategy(具体策略,如SimpleCompositor) —以Strategy接口实现某具体算法。 ?Context(上下文，如Composition) —用一个ConcreteStrategy对象来配置。 —维护一个对Strategy对象的引用。 —可定义一个接口来让Stategy访问它的数据。 7.协作 Strategy和Context相互作用以实现选定的算法。当算法被调用时,Context可以将该算法所需要的所有数据都传递给该Stategy。或者，Context可以将自身作为一个参数传递给Strategy操作。这就让Strategy在需要时可以回调Context。 Context将它的客户的请求转发给它的Strategy。客户通常创建并传递一个ConcreteStrategy对象给该Context；这样,客户仅与Context交互。通常有一系列的ConcreteStrategy类可供客户从中选择。 8.效果 Strategy模式有下面的一些优点和缺点: 1)相关算法系列 Strategy类层次为Context定义了一系列的可供重用的算法或行为。继承有助于析取出这些算法中的公共功能。 8.效果 2)一个替代继承的方法 继承提供了另一种支持多种算法或行为的方法。可以直接生成一个Context类的子类，从而给它以不同的行为。 但这会将行为硬行编制到Context中，而将算法的实现与Context的实现混合起来,从而使Context难以理解、难以维护和难以扩展，而且还不能动态地改变算法。 最后得到一堆相关的类, 它们之间的唯一差别是它们所使用的算法或行为。 将算法封装在独立的Strategy类中使得你可以独立于其Context改变它，使它易于切换、易于理解、易于扩展。 8.效果 3)消除了一些条件语句 Strategy模式提供了用条件语句选择所需的行为以外的另一种选择。 4)实现的选择 Strategy模式可以提供相同行为的不同实现。客户可以根据不同时间/空间权衡取舍要求从不同策略中进行选择。 8.效果 5) 客户必须了解不同的Strategy 本模式有一个潜在的缺点，就是一个客户要选择一个合适的Strategy就必须知道这些Strategy到底有何不同。此时可能不得不向客户暴露具体的实现问题。因此仅当这些不同行为变体与客户相关的行为时, 才需要使用Strategy模式。 8.效果 6) Strategy和Context之间的通信开销 无论各个ConcreteStrategy实现的算法是简单还是复杂, 它们都共享Strategy定义的接口。 因此很可能某些ConcreteStrategy不会都用到所有通过这个接口传递给它们的信息；简单的ConcreteStrategy可能不使用其中的任何信息！这就意味着有时Context会创建和初始化一些永远不会用到的参数。如果存在这样问题, 那么将需要在Strategy和Context之间进行更紧密的耦合。 8.效果