什么是设计模式，设计模式有什么用，解决了什么问题？
设计模式（Design Pattern）是一套被反复使用、多数人知晓的、经过分类的、代码设计经验的总结。

使用设计模式的目的：为了代码可重用性、让代码更容易被他人理解、保证代码可靠性。 设计模式使代码编写真正工程化；设计模式是软件工程的基石脉络，如同大厦的结构一样。

理论性的说明总是让人不易理解，只是知道是这样，而不明白内在的精华。那么我们通过以下的例子看看设计模式是怎样运用到我们的软件开发工程当中的。

小明开发一款鸭子游戏，鸭子会游泳，会呱呱叫。游戏的内部设计采用标准的OO技术，设计一个鸭子的超类，让各种鸭子继承此超类。 微信图片_20180605113636.png

完美的实现。

这时，小明又接到一个新的需求：让鸭子飞起来。

image.png

将游戏运行起来之后，发现一些“橡皮鸭”也飞起来了（bug）。在超类中添加的功能，有些子类是不需要的，这个怎么解决呢？
方法：子类覆盖fly方法，但是其中什么都 不做。这样这只橡皮鸭就不会飞起来了。完美。。。

额。。等等，这样的话，岂不是说，每只鸭子都需要检查一下它的各个功能呢。那得多复杂。看着电脑显示屏，小明又陷入了沉思... 这个电脑有显示的功能，不是跟鸭子需要飞行的功能一样么，电脑上留有接口，无论什么牌子的样式的显示器只要接口一样，都是可以接入到电脑当中的啊。
于是小明开心的又实现了一套设计：
将fly()作为接口当中的一个方法，需要飞的鸭子实现这个接口（接入显示器），就灵活的实现了这个功能，同样的，其他呱呱叫和游泳也可以这样去设计。这样就不会再有会飞的橡皮鸭，或者会呱呱叫的木头鸭了。

image.png

哎。。。等等，这样的话，，岂不是所有接口的方法实现当中 都需要写一遍 鸭子飞行的代码。。好坑啊！！！

那该怎么办呢，能否有这样一种方式，既对现有代码影响最小的方式来修改软件，这样的话，我们就可以花比较少的时间重做代码，而更专注与业务本身。

那么，我们尝试从问题本身出发，这是一款鸭子游戏，鸭子的行为在子类中会不断地改变，但是鸭子本身不会改变，它不会变成一只恐龙，对吧？
那么，我们可以知道这样的一种这样的设计原则：

找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。

所以，我们需要把鸭子和鸭子的行为分解开，将鸭子的行为fly和quack做为类去实现。鸭子只管对应的fly类和quack类就行了，而鸭子怎么飞，或者不能飞就交给fly类了。
这里可能很多人会讲类中不是定义属性和方法的吗，这些方法也可以抽象成一个类的么？
这就要引出第二个设计原则了：

针对接口编程，而不是针对实现编程。

我们通过具体分析来解释这个原则，我们利用接口代表每个行为，比如，FlyBehavior与QuackBehavior,而飞行类就实现FLyBehavior接口。所以鸭子类不实现具体的Fly与Quack接口，这些行为交由我们抽象出的行为类去实现对应的接口就可以了。如图：

image.png image.png

最后，我们可以生成不同的鸭子，调用不同的quack.

image.png

至此，小明就完成了这一次需求的改造，使得鸭子与它行为的耦合大大降低，扩展其他行为的能力大大提高。

然而，小明又接到一个需求，需要使鸭子装上火箭动力系统（小明的内心：这什么 * 游戏。。。），在模型鸭装上此系统时，飞行起来。。

小明看着这个需求翻白眼...咋办啊。原来的模型鸭是不会飞的，这戏加的。。

小明仔细的想了想，又露出了会心的一笑。不就是在飞行动作之前重新定义一下飞行类么，只要接口还是那个接口，这都不是难事。

微信图片_20180605160822.png

多用组合，少用继承。

由此，我们就分析完了策略模式。

正式定义如下：策略模式定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。