为什么要设计模式
软件开发中，我们花费更多的时间在需求变化和维护项目上，想更好得应对变化需要建立弹性的，可维护、可应对变化的设计。而知道抽象、继承、多态，并不能马上成为面向对象设计者，设计模式正是告诉我们如何组织类和对象以解决某种问题，所以需要设计模式。
其实我们正在使用的框架封装了很多设计模式，但是我们感觉不到。可以先让设计模式进入你的脑海，再尝试使用。
策略模式
现在有个模拟鸭子的游戏，游戏中出现各种鸭子，比如一边游泳，一边呱呱叫，每个鸭子的外形不同。使用面向对象（OO）技术，设计类图如下
duck1.png
需求变动，有些鸭子要添加飞的特性，会飞的特性代码添加在哪里呢？
- 父类 Duck 的实现代码中，这样会导致全部鸭子都会飞，明显不行。
- 解决方案，可以把 fly() 覆盖掉，使得鸭子不会飞。但也有鸭子会飞不会叫，采用同样的方法覆盖 quack()
- 缺点，很难知道鸭子全部行为、代码在多个子类中重复
- 利用接口，把 fly() quack() 方法接口出去
- 缺点，此时行为代码写在鸭子子类中，代码无法复用，如果有48个鸭子都要稍微修改一下飞行的行为，很容易出错
duck2.png
上面两种方式都不能解决问题，那是因为我们没有遵循设计原则
- 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
这样我们可以把飞和叫 的行为抽出成类，独立出去。类图如下
duck3.png
现在父类Duck 中只要 FlyBehaior QuackBehavior 两个行为接口引用就行了，在利用多态特性去调用飞和叫的方法，而且具体的方法实现也不会出现在Duck 或者Duck 子类中。
duck4.png
Duck 代码实现如下
public abstract class Duck{
FlyBehavior flyBehavior;
QuackBehavior quackBehavior;
public Duck(){
}
public void performFly(){
flyBehavior.fly();
}
public void performQuack(){
quackBehavior.quack();
}
public void swim(){
// .....
}
}
// 飞行为
public interface FlyBehavior{
public void fly{};
}
public class FlyWithWings implements FlyBehavior {
public void fly(){
//...
}
}
public class FlyNoWay implements FlyBehavior {
public void fly(){
// ...
}
}
// 实现 一个鸭子
public class MallardDuck extends Duck {
public MallardDuck(){
quackBehavior = new Quack();
flyBehavior = new FlyWithWings();
}
public void dispaly(){
// ...
}
}
这样就可以很方便添加飞行为的其他实现，这时全部类图
duck5.png
当然Duck 也可以提供set flyBehavior实现类的对象，使得鸭子对象在运行时能改变自己飞的行为形式
public void setFlyBehavior(FlyBehavior fb){
flyBehavior = fb;
}
策略者模式：定义算法族，分别封装起来，让他们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。其实在 重构 优化switch/case 语句中使用的就是策略模式。
欢迎大家给我留言，提建议，指出错误，一起讨论学习技术的感受！
