策略模式就是将变化的那部分行为抽离出来进行封装。行为抽象成一个接口，具体的行为实现去实现这个接口。
依赖接口，组合代替继承。
通过书中的鸭子模型来体验一下使用了策略模式会有哪些变化：
- 还没新需求的时候，使用了一个抽象的Duck父类，不同的鸭子类去在自己类中具体实现。
- 变化来了，客户需要Duck实现fly()，鸭子的飞翔方法。
那么，所有的子类都需要加一个fly()方法，一切感觉还不错...?
- 然鹅现实并没有这么简单...公司上市，前景大好，需求大增，需要更多的鸭子类，走向世界，老板拍拍你的肩膀：好好干，小伙子，以后公司会分股份...
然而你已经被新增的需求搞自闭了，所有的实现类Duck都需要在自己类中进行实现具体行为。
在软件开发中，后期的维护和修改耗费的精力和时间比开发新功能要多得多。
- 当行为一样的时候，需要在实现类写大量重复的代码
- fly()方法一旦需要更改逻辑或者修复bug，每个类中都要修改
我们可以看到，fly()的实现就是不断变化的，这就是没有把变化进行抽象封装的结果。
- 那么，什么是封装变化呢？
想想我们上面产生的问题，每个类都需要实现自己的fly()方法。
我们想要的是，每个Duck都有fly的行为，但是不负责对fly的具体实现。
我们把fly这个行为抽象成一个FlyBehavior接口，具体实现由FlyBehavior的实现类来具体实现。Duck实现类只需要依赖一个FlyBehavior接口。需要哪个fly()方法，只需要new XXflyBehavior()，然后调用它的fly()方法就好了。
这样解决了这两个问题。
- 当行为一样的时候，需要在实现类写大量重复的代码
- fly()方法一旦需要更改逻辑或者修复bug，每个类中都要修改
现在一种fly方式只需要实现一次，可以多处调用。
修改fly方法只需要去对应的实现类进行修改，只修改一处。
这就是行为抽象成一个接口，具体的行为实现去实现这个接口。依赖接口，组合代替继承。
最后升华一波，看看策略模式的UML图。
针对接口编程，而不是针对实现编程。
多用组合，少用继承。
抽象出可能变化之处，独立出来。
总结与思考
我通过一个简单的鸭子模型讲述了因为使用了继承的设计导致需求变化的时候工作量变大，然后通过改良设计来降低项目复杂度的过程。我自我感觉写的比较简单易懂了。但是总觉得哪里不对，思考了一阵子我得出了自己的结论。文章中一开始给出了一个bad design，然后需求来了，我们去改良成good design。中间少了一个步骤，就是怎么思考出降低复杂度的设计这个思考过程。在工作流程中，我们遇到了不好的设计，我认为的步骤应该是：
- 嗅出项目中不好的设计
- 思考如何改良，如果现在的是不好的，那么什么是好的？
- 进行改良
我这篇文章，通过需求的变更，工作量剧增，我们可以得出这个项目中使用继承的设计是不好的。
然后我们给出好的设计，缺少了中间思考的部分。这正是需要我们通过不停的锻炼才能得到的能力。
我们经常说“23个设计模式”，在我看来这就是写代码的23个套路。我们通过了解设计模式，可以了解一些例子从bad->good的过程，有利于我们觉察出实际项目中的不良设计。
