聊
最近一直在繁忙的工作中，博客在上周搞好之后一直没有更新，但是学习的步伐没有停滞，如果说我一开始干开发的动力来源于提升生活质量，进入开发后持续学习的动力就来自于兴趣，那现在分享、交流就是驱动我进步的又一个动力，如果你评论栏里留言我觉得就像给一个奔驰的火车又添加燃料。鉴于时间的分配，我觉得一周更新一次比较恰当。这是第一篇学习的记录《设计模式》之策略模式，分享给大家。
记
先看一个场景：一个鸭子的游戏，说游戏中会出现各种鸭子，一边游泳戏水，一边呱呱叫，用面向对象的技术设计了一个鸭子的父类。
所有的鸭子只负责实现自己的display() 方法。在一次股东会议上主管认为该是创新的时候了，并决定需要用会飞的鸭子将竞争者抛在后头，程序员拍胸脯说一个周就可以搞定，于是在父类上给鸭子增加了fly()方法。
但是可怕的事情发生了，主管在演示时，屏幕上出现了一只“橡皮鸭子”飞来飞去，问程序员，你是在开玩笑吗？你可能要开始去逛智联招聘了。
书中的一个小故事，我觉得这本书不错，用模拟生活中的案例的方式比较能让我更直观的了解到方法的应用。并且小故事很有意思，会帮助人的大脑加深记忆。我还看过一本《程序员内外兼修》的书，里面介绍了许多学习的方法，有时间和大家一起分享。
程序员开始想办法解决这个事情，第一时间想到了继承的重写方法。可是，如果以后要加入木头鸭该怎么办，木头鸭子不会飞也不会叫。
程序员认识到继承可能不是答案，主管希望以后每六个月更新产品，至于更新的方法，他们还没想到，这样每当有新的鸭子子类出现，他就要被迫检查并可能需要覆盖所有的fly和quack方法。
程序员想到用接口的方式实现，将fly()从超类中取出来，放进一个“Flyable接口”中。这样只有会飞的鸭子继承此接口，同样的方式也可以制作一个“Quackable接口”。
你觉得这个设计如何？（先想一想）
:这样虽然能让橡皮鸭不会飞，但是却增加了更多的重复代码，飞行的动作可能还会有多种变化，所以这不是最终的答案，其中书中还讲了好多反例及原因，这里就不一一举例了。下面将利用真正的设计方法和原则来改造这个鸭子游戏。
- 设计原则：独立出应用中可能需要变化部分，不要和那些不需要变化的代码混在一起。
- 设计原则：针对接口编程，而不是针对实现编程
- 设计原则：多用组合，少用继承
第一步：将鸭子的行为从父类中提取出，并放在分开的类中，此类专门提供某行为的接口实现，这样鸭子类就不需要知道行为的实现细节。分别是FlyBehavior接口表示飞行行为，QuackBehavior接口表示叫行为。并且分别实现一组行为方法。
第二步：将鸭子飞行和叫的动作委托给FlyBehavior和QuackBehavior处理，而不是把实现类定义在Duck类或子类中。在Duck类中加入两个实例变量分别是“flyBehavior”与“quackBehavior”，声明为接口类型而不是实现，运行时引用正确的行为。将用performFly和performQuack取代原来的fly和quack方法。
第三步：实现第一支鸭子,文章大多使用UML图例其他接口及抽象类可按照UML实现。我已经将代码公布到GitHub中，可以参照或指点。[https://github.com/lucksbrother/studyDesignPattern]
public class MallardDuck extends Duck {
public MallardDuck() {
flyBehavior = new FlyWithWings();
quackBehavior = new Quack();
}
@Override
public void display() {
System.out.println("我是绿头鸭");
}
}
测试：
public class TestMain {
public static void main(String[] args) {
Duck mallard = new MallardDuck();
mallard.display();
mallard.performQuack();
mallard.performFly();
}
}
至此策略模式已初步应用到鸭子游戏中。在文中有一处并未完全实现设计原理的针对接口编程，在后续的学习中会有其他设计模式修正这一点。
记
策略模式定义了算法族,分别封装起来,让他们之间可以互相替换,此模式让算法的变化独立于使用算法的客户.
