【HeadFirst设计模式】策略模式

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/wcm_lucky/article/details/89207191

设计原则：

• 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码放在一起。
  • 把会变化的部分取出并封装起来，以便以后可以轻易地扩充此部分，而不影响不需要变化的其他部分。
  • 这样的概念很简单，几乎是每个设计模式背后的精神所在。所有的模式都提供了一套方法让「系统中的某部分改变不会影响其他部分」
• 针对接口编程，而不是针对实现编程
  • 我 们 利 用 接 口 代 表 每 个 行 为 ， 比 方 说 ， F l y B e h a v i o r 与Q u a c k B e h a v i o r，而行为的每个实现都必须实现这些接口之一。所以这次鸭子类不会负责实现 F l y i n g与 Q u a c k i n g接口，反而是由其他类专门实现 F l y B e h a v i o r与 Q u a c k B e h a v i o r，这就称为「行为」类。由行为类实现行为接口，而不是由 D u c k类实现行为接口。
    这样的作法迥异于以往，以前的作法是：行为是继承 D u c k超类的具体实现而来，或是继承某个接口并由子类自行实现而来。这两种作法都是依赖于「实现」，我们被实现绑得死死的，没办法更改行为（除非写更多代码）。
    在我们的新设计中，鸭子的子类将使用接口（ F l y B e h a v i o r与Q u a c k B e h a v i o r）所表示的行为，所以实际的「实现」不会被绑死在鸭子的子类中。（换句话说，特定的实现代码位于实现F l y B e h a v i o r与 Q u a k c B e h a v i o r的特定类中）。
• 多用组合，少用继承
  • 如你所见，使用组合建立系统具有很大的弹性，不仅可将 算 法 族 封 装 成 类 ， 更 可 以 『 在 运 行 时 动 态 地 改 变 行
    为』，只要组合的行为对象，符合正确的接口标准即可。
• 『策略模式』
  • 定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。
• 策略模式设计举例
  • 动作冒险游戏：代表角色的类，代表武器行为的类，每个角色一次只能使用一件武器，但可以游戏过程中更换武器                                C h a r a c t e r（角色）是抽象类，让具体的角色继承之。具体的角色包括：国王（ K i n g）、皇后（ Q u e e n）、骑士（ K n i g h t）、妖怪（T r o l l）。而 W e a p o nBehavior（武器）是接口，让具体的武器继承之。所有实际的角色和武器都是具体类。任何角色如果想换武器，可以调用 s e t W e a p o n ( ) 方法，此方法定义在 C h a r a c t e r超类中。在打斗（ f l i g h t）过程中，会调用到目前武器的 u s e W e a p o n ( ) 方法，攻击其他角色。