写在开始
设计模式是作为一个开发人员老生常谈的东西，但经常是“谈”的多、“用”的少。所以我自己经常有这样的感觉，虽然重复看了很多次各种设计模式的相关文献，但时间久了之后，某时刻当自己作为一个被提问者被问起“xxx这段代码中用了什么设计模式？”或“针对现在这坨shit一样的代码，你觉得用什么模式重构一下比较好？”这类问题的时候却不能对答如流。但是当被提的问题答案公布的时候，心里却不经泛起“卧槽，这TM我知道啊，但是就是想不起啥名字。。。”、“我NM知道这么去重构啊，但是这货的名字我却对不上。。。”这样的答案。
设计模式真的“谈”的多、“用”的少吗？我觉得不是，其实对于一些常用的设计模式如“策略”、“工厂”、“模板方法”、“适配器”等这类模式，其实在我们日常开发中已经在不知不觉中应用了，只是我们个人疏于回顾和总结，所以当真正见到这个名字的时候可能会一脸懵逼。
模式是什么？模式是在某种情况下，针对某问题的某种解决方案。对于软件开发而言，使用设计模式能够在某些场景下，使得软件更加有弹性、更易扩展。因此，学习设计模式最终目的是能够在正确的场景下，使用正确的模式，使得开发出的软件能够拥有良好的弹性和扩展性。
我们都能把设计模式用好吗？就我个人而言，目前达到的状态仅仅是“这个场景下，用XX模式可能会好一些”，但是真正把设计模式理解的非常透彻的人，我想他们的状态应该是“在这个场景下，采用XX模式相当自然”。
为了能向终极状态迈进，最近尝试把之前学习过的、常见的设计模式梳理和总结一下（尽管有些确实很简单），一方面希望能够使自己对设计模式能够融会贯通，挖掘并领悟模式背后的软件设计哲学思想；另一方面培养自己的梳理总结能力，鞭策自己后续在读书学习之后能够实时梳理总结（总结比读书更重要）。
我的设计模式启蒙书籍是《Head First 设计模式》，里面对设计模式讲解浅显易懂，但过渡性文字和图片较多（但确实是一本非常适合入门的书籍），接下来的内容也大多沿用了这本书籍里面的示例。
介绍策略模式
策略模式是最常见、常用的一种模式，下面通过一个示例来描述一下策略模式的使用场景和使用方式。（示例借鉴《Head First 设计模式》）
在这里你有一个鸭子的类，它里面有quack()、swim()、display()方法，分别表示鸭子叫声、游泳和鸭子外表样子。如下所示：
// Duck.java
public class Duck {
public void quack(){
System.out.println("嘎嘎。。");
}
public void swim(){
System.out.println("我会游泳");
}
public void display(){
System.out.println("我是黄色的鸭子");
}
public void run(){
quack();
swim();
display();
}
}
但是在你的需求中，鸭子有好多种，但是它们的共性就是都是嘎嘎叫，并且都会游泳，唯一不同的就是外表，此时拥有OO思想的你会通过如下方式实现：
// WoodDuck.java
public class WoodDuck extends Duck {
@Override
public void display() {
System.out.println("我是木头鸭子");
}
}
// PlasticDuck.java
public class PlasticDuck extends Duck {
@Override
public void display() {
System.out.println("我是塑料的鸭子 ");
}
}
以上的实现方式在上述场景是完全正确的，通过使用继承对方法进行了有效的复用。这时候此次需求完成了，项目也如期交付了，如下所示。
public class ProjectStart {
public static void main(String[] args) {
Duck duck = new Duck();
duck.run();
Duck plasticDuck = new PlasticDuck();
plasticDuck.run();
Duck woodDuck = new WoodDuck();
woodDuck.run();
//.....假设这里new了20只鸭子
//.... 这里假设这个main方法的执行就意味着项目运行起来了
}
}
就这样，很长一段时间以后，你突然接到一个需求：需要在鸭子项目中增加一种会飞的鸭子。这个时候，聪明的你在窃喜，因为你早已考虑到会有变化，由于使用了继承这一伟大手法，此时你的脑海里有两种思路：
- 直接在Duck类中增加fly方法，并给出默认实现
- 将原本的Duck改为了抽象类，增加了fly抽象方法
通过缜密的思考，你直接把方法1pass掉了，因为那样会直接导致上线后之前的“木头鸭”、“塑料鸭”等直接飞起来，这样造成的损失把你裤衩卖了都还不清。
因此，方法2成了最佳的选择，于是你立刻对原先的代码进行了如下的改进：
public abstract class Duck {
public void quack(){
System.out.println("嘎嘎。。");
}
public void swim(){
System.out.println("我会游泳");
}
public void display(){
System.out.println("我是黄色的鸭子");
}
public void run(){
quack();
swim();
display();
fly();
}
abstract void fly();
}
“原来的new Duck()编译不通过？没关系，我再增加一个DefaultDuck类继承Duck类，通过new DefaultDuck()用来顶替new Duck() 不就行了吗？（嘴角渐渐扬起了得意的笑容）”
但是，当你刚写完DefaultDuck的时候，你就准备要吐血了，因为发现原来的20多只鸭子类都需要重写一个新加的fly()方法。“Oh, Shit！W.T.F！！！！”
显然继承并不是在任何时候都是一种好的实现方案。
此时，你平复了你的心情，你不断的对自己说“要冷静、要冷静。。。”，你知道，一切都是自己的冲动，但是好在你及时意识到这个问题。于是，你这次决心要找一种万全的方法来解决当前这个问题。
这个时候，一个设计原则浮现在了你的脑海：
找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混合在一起。
根据上述原则，通过分析你发现，在Duck中disply()和这次增加的fly()，以及未来可能扩展的属性都属于会变化的，而swim()和quack()是所有鸭子都会有的属性，它们是不会变化的。
找到了变化的和不变的，接下来该怎么办呢？你绞尽脑汁又陷入了沉思，这个时候三年前学过的一个设计原则，又闪过了你的脑海：
针对接口编程，而不是针对实现编程
这时你嘴角渐渐扬起了微笑，这个原则你当时深入研究过，你明白其背后的深入含义。
所谓程序开发中的接口可以映射为业务需求中的行为，在当前的需求中，鸭子的行为分别有：quack()、swim()、display()、fly()。针对这些行为，其中quack()、swim()这两个行为在目前以及可以预见的未来都是不变的；但是display()、fly()这些是一直会发生变化的，当然还有一些未来可能会增加的行为，这也属于变化的范畴。
经过上述的思考，你计划做出两个改动：
- 根据上述第一个设计原则，你计划将display和fly这两个变化的行为从Duck中剥离出来，不在和那些不变的行为混合在一起。
- 根据上述第二个设计原则，你计划先设计两个接口，用来表示display和fly这两个行为。
于是你很快先设计了如下两个接口如下所示：
// DisplayBehavior.java
public interface DisplayBehavior {
void display();
}
// FlyBehavior.java
public interface FlyBehavior {
void fly();
}
同时你也对Duck类进行了如下改动：
// Duck.java
public class Duck {
protected DisplayBehavior displayBehavior;
protected FlyBehavior flyBehavior;
public Duck() {
}
public Duck(DisplayBehavior displayBehavior, FlyBehavior flyBehavior) {
this.displayBehavior = displayBehavior;
this.flyBehavior = flyBehavior;
}
public void quack(){
System.out.println("嘎嘎。。");
}
public void swim(){
System.out.println("我会游泳");
}
public void display(){
if (Objects.nonNull(displayBehavior)){
displayBehavior.display();
}else {
System.out.println("我是黄色的鸭子");
}
}
public void fly(){
if (Objects.nonNull(flyBehavior)){
flyBehavior.fly();
}
}
public void run(){
quack();
swim();
display();
fly();
}
}
之后，你又在项目中增加了两个实现了fly、display这两个行为接口的策略类
// FlyWithWings.java
public class FlyWithWings implements FlyBehavior {
@Override
public void fly() {
System.out.println("我是会飞的鸭子");
}
}
// WhiteDisplay.java
public class WhiteDisplay implements DisplayBehavior {
@Override
public void display() {
System.out.println("我是白色的鸭子");
}
}
这个时候你嘴角得意的微笑已经逐渐在放大了，是的你的外表已经无法掩盖内心的喜悦。
于是乎，你在项目原本的项目代码中重新增加了一个会飞的鸭子类（FlyDuck.java），并对原本的运行代码进行简单的修改，你的需求如期交付了。
// FlyDuck.java
public class FlyDuck extends Duck{
public FlyDuck() {
flyBehavior = new FlyWithWings();
displayBehavior = new WhiteDisplay();
}
}
// ProjectStart.java
public class ProjectStart {
public static void main(String[] args) {
Duck duck = new Duck();
duck.run();
Duck plasticDuck = new PlasticDuck();
plasticDuck.run();
Duck woodDuck = new WoodDuck();
woodDuck.run();
//.....假设这里new了20只鸭子
Duck flyDuck = new FlyDuck();
flyDuck.run();
//.... 这里假设这个main方法的执行就意味着项目运行起来了
}
}
这个时候，你轻轻推了一下眼镜，喝了一口桌边还有余温的咖啡，心里默默的感叹“有文化的人不伤心！”
总结
到目前为止，一个策略模式你已经巧妙的应用在你的项目中了（上述示例不是最好的，理解意思就行）。
总结一下，在鸭子这个项目中所谓的策略，就是把fly()、display()这些变化的行为单独剥离出来抽象成接口，并根据具体的需求通过实现这个接口构建对应的策略类。
而后，在策略使用方中（示例中的Duck），你就可以通过动态的替换策略类（示例中的替换方法是构造器，但实际中替换的方法还可以是set方法等其他方式），以使你的使用方实施不同的策略。
通过上述的思考过程中不难发现，有时候继承不一定是最好的选择，上述方案中最终通过使用组合的方式，来弥补了这一不足。这也就是另一个最常提起的设计原则。
多用组合，少用继承
其实最关键的还没有提到，那就是到底什么时候该使用策略模式？ 针对上述的示例，之所以使用策略模式是因为两个方面：
- 项目中未知的变化太多，因此需要将有变化的行为进行剥离
- 继承已经不能解决当前需求的问题
而之所以有这两个动机的原因，最根本的原因是有上述三个设计原则作为最基本的指导思想。我相信在其他的场景下会有更多的原因促使你使用策略模式来解决一些问题，但是最终的指导思想都是一样的。
所以我觉得，当我们学会了设计模式以后在日常开发的过程中，不应该任何时候都生搬硬套的把某个模式应用到你的代码中，而是应该在面对问题时，从设计原则进行思考，让原则作为指导思想来促使你思考，进而得出使用哪种方式来解决问题。我相信最终的解决方式不一定是某个设计模式。
后记
很长一段时间以后，你的组里新进了一个实习生，他和你一块负责完善鸭子项目，突然有一天他问你。
实习生：“大哥，你这代码风格怎么不一致呀？怎么有的鸭子自己重写了display方法，有的鸭子是在构造的时候用了一个DisplayBehavior实现类？”
你：“额。。。历史遗留问题。。要不，你有时间的话改改吧。。。”
实习生：“好吧。”（内心OS：这代码写的真烂，老一辈程序员真不行！）
突然，产品经理找你，鸭子项目有新的迭代，说要增加一种新的鸭子行为。你思考了三秒钟，让产品经理直接找实习生来搞吧。
产品经理：“你好，这边鸭子项目需要增加一种会唱歌的鸭子，你大哥让你来搞一下”
实习生：“啊？？我才刚入职2天啊。。好吧，我看下。。”（内心OS：这帮上班久了的人真是老油条啊，啥TM都不用干）
产品经理：“请问大概啥时候能完成？”
实习生：“额。。。”（此时实习生看出使用了策略模式，嘴角露出微笑）“给我2个小时时间吧！”