设计模式--Strategy Pattern 策略模式

从现在开始，假设我们是一家软件公司的职员，有个项目让我们做，有客户要我们创建一个名为SimUDuck的app（本文中一律用E文app代替中文“应用程序”）
SimUDuck是个有关鸭子的模拟程序，它可以显示各种不同种类的鸭子，模拟它们游泳，嘎嘎叫等行为。呵呵，很简单的吧。
我们当然要使用OO（本文中一律用E文OO代替中文“面向对象”）的技术和思想来实现这个程序。
所以呢，首先要创造Duck这个superclass（父类），所有种类的鸭子就可以从它继承了。这可是面向对象三态中最基本的一点哦。
Duck父类的代码基本上有以下方法组成：
Quack() ；//所有的鸭子都会叫，所以这些方法在父类中实现
Swim() ；//所有的鸭子都会游泳，所以这些方法在父类中实现
Display()； //因为不同的鸭子样子不同，所以要留到具体的子类去实现，把它先写出抽象类
继承Duck的子类，比如MallardDuck和RedheadDuck就要分别去具体实现display方法了，因为它们是不同种类的鸭子，所以display当然不同了。
代码的初步基本上写完了。利用了继承，貌似很完美。
可是~~~问题来了。
什么问题呢？就是，现在程序要添加一个功能：让鸭子飞起来。
客户是上帝嘛~在他们看来，让程序新增加一个功能应该不是难事吧。
恩，正常人的思维就是在父类里加上fly（）方法，因为我们使用了继承这一OO技术，所以所有的鸭子都能继承到，很不错吧。
但是，程序出现bug了。
客户说，在他们的预想的程序中，有一种鸭子是RubberDuck（哦，我的天，橡胶小鸭），这种鸭子明显不能飞的嘛。
怎么办？利用继承的坏处显现出来了。它让所有的鸭子，不管活鸭死鸭都飞起来了。
/****************************************************************************/
思考下
/***************************************************************************/
解决的办法是有的。就是在RubberDuck这个子类中override（重写）一下fly（）方法，让它不能飞。
可是这是一种治标不治本的方法，假如程序中还有别的像RubberDuck这样不能飞的鸭子，比如WoodDuck（木头小鸭），岂不是也要在这个子类中override一下fly（）方法，一个类两个类override一下的话可以接受，一旦有成千上万个类要override的话，效率岂不是很低？
灵感闪现！看来继承是解决不了这个问题了，我们得另辟蹊径，interface怎么样？
我们可以把fly（）实现成一个接口Flyable，让那些需要fly的鸭子去实现这个接口，而所有鸭子都需要的方法还是写在父类中。貌似不错的解决方法。
其实这么做的话很明显就是为了使用接口而去使用接口，因为在JAVA中，接口中是不实现任何方法的，所以这么做无疑是在浪费时间，还不如老老实实的在需要fly的类中，手动地添加fly方法呢。

现在我们要去思考的，是我们所遇到的问题究竟是什么？

在软件开发中，唯一不变的东西就是变化。无论你的程序在一开始写的多棒，功能有多完善，随着时间的流逝，程序一定会在使用中面临新的要求和变换以迎合客户的需求。
所以，不变则死！
我们要做的就是，do so with the least possible impact on the existing code that we could spend less time reworking code
以上便是软件设计的真谛。
下面是三条是很著名的设计原则：
1.Identify the aspects of your application that vary and separate them from what stays the same.
2.Program to an interface ,not an implementation.
3.Favor composition over inheritance.
简单的翻一下：
1.把程序中不变的部分和变化的部分隔离开来。
2.针对接口编程，而不是实现。
3.尽量多用组合，少用继承。
根据原则1，我们或许已经知道了解决Duck类中fly这个不合群方法的方法。
就是把它独立出去，单独形成一个类吧。
根据原则2，我们可以设计FlyBehavior这么一个接口，以及FlyWithWings和FlyNoWay这么两个类，以满足不同的需要。

最终的解决方案如下所示，它包含Duck抽象类，FlyBehavior接口，FlyWithWings和FlyNoWay这两个实现了接口的类，和最终的main方法：
abstract class Duck {
FlyBehavior flyBehavior;
public abstract void display();
public void performFly() {
  flyBehavior.fly();
}
public void swim() {
  System.out.println("all duck swim");
}
}
interface FlyBehavior {
public void fly();
}
class FlyWithWings implements FlyBehavior {
public void fly() {
  System.out.println("i am flying");
}
}
class FlyNoWay implements FlyBehavior {
public void fly() {
  System.out.println("i can not fly");
}
}
class MallardDuck extends Duck {
public MallardDuck() {
  flyBehavior = new FlyWithWings();
}
public void display() {
  System.out.println("i am a real mallardduck!");
}
}
class ModelDuck extends Duck {
public ModelDuck() {
  flyBehavior = new FlyNoWay();
}
public void display() {
  System.out.println("i am a ModelDuck");
}
}
public class MiniDuckSimulator {
public static void main(String[] args) {
  Duck mallard = new MallardDuck();
  mallard.performFly();
  Duck modelduck=new ModelDuck();
  modelduck.performFly();
}
}
运行结果如下：
i am flying
i can not fly
仔细回味一下程序这么写的好处。比起一开始的设计，优点是什么？
从现在的设计中，我们可以发现，Duck类现在没有了fly（）方法，而是把它委派给了FlyBehavior这一接口。
这就是今天最终要引出的主角：Strategy Pattern 策略模式
Gof对它的定义是：Ths strategy pattern defines a family of algorithms,encapsulates each one ,and makes them interchangeable.Strategy lets the algorithm vary independently from clients that use it.
先到此休息会。