从鸭子游戏设计看设计模式

策略模式

1.什么是策略模式

​ 策略模式作为一种软件设计模式，指对象有某个行为，但是在不同的场景中，该行为有不同的实现算法。比如每个人都要“交个人所得税”，但是“在美国交个人所得税”和“在中国交个人所得税”就有不同的算税方法。

2.案例

需求是设计一个模拟鸭子的游戏.游戏中会出现各种的鸭子,一边游泳戏水,一边呱呱叫(不同种类的鸭子的叫声不一样),一边飞行(部分鸭子不会飞).

1.使用继承的设计方法

如果所示设计一个Duck的超类,里面将所有的方法都带上,让其他类型的鸭子去继承这个Duck超类.问题是在超类中加上fly() 就会导致所有的子类都具备fly(),连那些该具备fly()的子类也没法免除.当涉及"维护"时,为了"复用"(reuse)目的而使用继承,结局并不完美.

2.利用接口

通过将Duck中的fly() 和 quack() 方法独立出来.设计两个接口Flyable和Quackable接口,需要实现这两个方法的鸭子继承Duck类并且实现Flyable接口.这样子的缺点是,我们知道，并非“所有”的子类都具有飞行和呱呱叫的行为，所以继承并不是适当的解决方式。虽然Flyable与Quackable可以解决“一部分”问题（不会再有会飞的橡皮鸭），但是却造成代码无法复用，这只能算从一个恶梦跳进另一个恶梦。甚至，在会飞的鸭子中，飞行的动作可能还有多种变化……

3.使用策略模式

设计原则1:找出应用中可能需要变化之处,把他们独立出来,不要和那些不需要变化的代码混合在一块.

设计原则2:针对接口编程,而不是针对实现编程

我们利用接口代表每个行为，比方说，FlyBehavior与QuackBehavior，而行为的每个实现都将实现其中的一个接口。所以这次鸭子类不会负责实现Flying与Quacking接口，反而是由我们制造一组其他类专门实现FlyBehavior与QuackBehavior，这就称为“行为”类。由行为类而不是Duck类来实现行为接口。

这样的做法迥异于以往，以前的做法是：行为来自Duck超类的具体实现，或是继承某个接口并由子类自行实现而来。这两种做法都是依赖于“实现”，我们被实现绑得死死的，没办法更改行为（除非写更多代码）。

在我们的新设计中，鸭子的子类将使用接口（FlyBehavior与QuackBehavior）所表示的行为，所以实际的“实现”不会被绑死在鸭子的子类中。（换句话说，特定的具体行为编写在实现了FlyBehavior与QuakcBehavior的类中）。

最终设计umi图

Duck超类

package com.demo.designpattern.crachKnolodge;

public abstract  class Duck {
   
   
    public FlyBehavior flyBehavior;
    public QuackBehavior quackBehavior;

    public Duck(){
   
   

    }

    public