参考答案：依题意，在图1中，Duck为抽象类，描述了抽象的鸭子，方法fly()、quack()和display()分别表示不同种类的鸭子都具有飞行特征、发声特征和外观特征；而类RubberDuck、MallardDuck、CottonDuck和RedHeadDuck分别描述具体的鸭子种类；类Fly Behavior与QuackBehavior为抽象类，分别用于表示抽象的飞行行为与发声行为；类Fly NoWav与Fly WithWings分别描述不能飞行的行为和用翅膀飞行的行为；类Quack、Squeak与QuackNoWay分别描述发出“嘎嘎”声的行为、发出橡皮与空气摩擦声的行为和不发声的行为。鉴于不同的鸭子种类只是在行为方面有所区别，且为支持将来能够模拟更多种类鸭子的特征，该公司架构师最有可能采用策略(Strategy)设计模式来设计如图1所示的模拟鸭子游戏软件。
Strategy模式定义了一组能够用来表示可能行为集合的类。这些行为可以在应用程序中使用，来修改应用程序功能。Strategy(策略)模式的设计意图是，定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换，使得算法可独立于使用它的客户而变化。具体而言，该模式是一种定义一系列算法的方法，从概念上看，所有这些算法完成的都是相同的工作，只是实现不同，它可以以相同的方式调用所有的算法，减少了各种算法类与使用算法类之间的耦合。Strategy模式的一般结构如图2所示。
图2

Strategy模式具有以下一些优点和缺点。
(1)另一种子类化方法。Strategy类层次为Context(上下文)定义了一系列的可供重用的算法或行为。继承有助于析取出这些算法中的公共功能。可以直接生成一个Context类的子类，从而给它以不同的行为。但这会将行为强制编制到Context中，而将算法的实现与Context的实现混合起来，从而使Context难以理解、难以维护和难以扩展，而且还不能动态地改变算法。最后得到一堆相关的类，它们之间的唯一差别是它们所使用的算法或行为。将算法封装在独立的Strategy类中使得架构师可以独立于Context而改变它，使它易于切换、理解和扩展。
(2)在类自身中定义了每一个行为，从而减少了一些条件语句；Strategy模式提供了用条件语句选择所需行为以外的另一种选择。当不同的行为堆砌在一个类中时，很难避免使用条件语句来选择合适的行为。将行为封装在一个个独立的Strategy类中消除了这些条件语句。
(3)更容易扩展模型，即在不对应用程序进行代码修改的情况下，使该模式具有新的行为。
(4)客户必须了解不同的Strategy。该模式有一个潜在的缺点，就是一个客户要选择一个合适的Strategy就必须知道这些Strategy到底有何不同。此时可能不得不向客户暴露具体的实现问题。因此仅当这些不同行为变成与客户相关的行为时，才需要使用Strategy模式。
(5)Strategy和Context之间的通信开销。无论各个ConcreteStrategy(具体策略)实现的算法是简单还是复杂，它们都共享Strategy定义的接口。因此很可能某些ConcreteStrategy不会都用到所有通过这个接口传递给它们的信息；简单的ConcreteStrategy可能不使用其中的任何信息。这就意味着有时Context．会创建和初始化一些永远不会用到的参数。如果存在这样问题，那么将需要在Strategy和Context之间进行更加紧密的耦合。
(6)增加了对象的数目。Strategy增加了一个应用中的对象的数目。有时可以将Strategy实现为可供各Context共享的无状态的对象来减少这一开销。任何其余的状态都由Context维护。Context在每一次对Strategy对象的请求中都将这个状态传递过去。共享的Strategy不应在各次调用之间维护状态。