快一个多月没有技术博客，由于某种原因吧！今天开始继续写吧！继续学习提高自己技术能力吧！
我想写的是关于设计模式中的策略模式，我所写的内容都是我在看完了《Ｈｅａｄ Ｆｉｒｓｔ 设计模式》之后的想法、笔记以及总结吧！
怎么开头呢！ 按照书中逻辑书写顺序开头吧！
第一：书中给我们一个需求--模拟鸭子的应用SimUDuck系统！它要求在该系统中鸭子可以游泳、呱呱叫。
就这么简单：我们很容易设计，一个鸭子基类，在该基类中有游泳行为方法、呱呱叫行为方法、什么颜色方法，所有鸭子子类继承鸭子基类即可，重写颜色方法即可！目前这种设计完全可以应对目前系统需求。
我们利用UML工具记录我们目前设计：
很容易吧！好了系统上线运行ok。
第二：系统上线运行一段时间后，需求有所改变：要让鸭子飞起来！现在对我们的设计我们很容易就可以想到在Duck基类中添加飞行为方法即可！这样子鸭子就可以全部飞起来。从而现在我们的需求设计变成了：
第三：ok，到目前为止，我们所有的设计我们认为没有问题，但是现在根据用户的反馈问题来了，啥子问题吗！？
在该系统中，很多橡皮鸭子也飞起来了，显然有问题的！橡皮鸭子不能飞起来的。哦，现在我们清楚了，系统中的鸭子并非真实的鸭子动物，从而现在我们应该就会想到"继承"中重写fly()方法，也就是说在橡皮鸭子类中我们重写fly()方法，在该方法中我们不做任何处理，那么现在用户反馈的问题我们解决了，高兴吧！
，现在我们思考现在的设计？
橡皮鸭子不能飞，是不是也不能呱呱叫，那么我们还需要重写quack()方法。将来鸭子添加新的行为方法，我们还需要考虑子类所有鸭子是否该拥有新的行为方法，要是不该拥有新的行为方法，我们就重写对应的行为方法。这样子的话，我们是否感觉到了“子类和父类的强依赖关系”，代码的冗余、复用呢！？这样子的话，会使我们维护该系统非常累啊！
根据我们的思考我们又想到了别的设计--利用接口
第四：我们可以利用接口的形式来设计，我们可以将有可能发生该变的行为抽取出来作为行为接口，子类当中有符合该行为的鸭子由它来实现该行为接口即可。现在为止，不错我们可以解决了"子类和父类的强依赖关系“、代码的冗余问题
那么现在我们的设计改变成了
好了，到现在我们的系统已经解决了"子类和父类的强依赖关系“、代码的冗余问题，在有新行为添加的时候，我们只是需要添加新的行为接口，在需要新的行为的鸭子类实现对应的行为接口即可！
，这个时候我们可能又会在想，鸭子飞的行为代码复用问题还并未解决！？
介绍到了这里，我们的系统设计还是存在问题，在往下介绍就要介绍我们今天所要谈到的正题了，利用策略模式来解决问题！
我们先了解面向oo设计三大原则：
第一：我们要尽可能的找出系统中可能会发生改变的地方代码，将可能发生改变的地方代码和一定不会发生改变的地方代码分开，不要混淆在一起。
第二：我们要针对接口编程，而不要针对实现过程编程。
第三：多用组合，少用继承。
根据上面的三大原则，我们将系统重新设计为：
现在我们的设计中的代码冗余、代码不可复用的问题已经解决了，系统鸭子如果要添加一个新的快飞的行为动作的话，我们只是需要新建一个鸭子快飞行为动作类实现FlyInterface接口即可，在我们接口实例的时候，构造对应的实例对象就可以了，从而将fly飞的代码剥离出来。从而代码不可复用问题，代码冗余问题得到了车底解决。
以上的系统设计在设计模式中就是所谓的策略模式。
好了，那么我们为策略模式做一个具体定义：
策略模式定义了一系列的算法，将每一个算法封装起来，每一个算法之间可以相互替换，策略模式让算法独立使用于他的客户而独立变化。
哈勒，就写到这篱笆！ 休息了，！ 祝大家元旦快乐。