这是设计模式系列的第一篇，系列文章目录如下：
虽然不同的设计模式解决的问题各不相同，但从一个更高的抽象层次来看，它们通过相同的手段来实现相同的目的。本文将以更抽象的视角剖析工厂模式、策略模式、模版方法模式，以及这些模式所遵循的设计原则。先用一句话总结它们的共同点：
它们增加了一层抽象将变化封装起来，然后对抽象编程，并利用多态应对变化。
应用这些设计模式的项目实战可以移步下面的链接：
工厂模式
1. 变化是什么
对工厂模式来说，变化就是构建对象的方式，举个例子：
public class PizzaStore{ public Pizza orderPizza(String type){ Pizza pizza ; //构建具体pizza对象 if(type.equals("cheese")){ pizza = new CheesePizza(); }else if(type.equals("bacon")){ pizza = new BaconPizza(); } //使用pizza对象 pizza.prepare(); pizza.bake(); return pizza ; }}复制代码 抽象的反义词是具体，对于工厂模式，具体就是用new来构建对象。这样做的后果是PizzaStore不仅需要引入具体的Pizza类，而且和构建Pizza的细节耦合在一起。
如果PizzaStore一辈子只做这两种Pizza，上面的代码就很好，不需要重构。但如果需要新增Pizza类型，就不得不修改orderPizza()，向其中增加if-else。
2. 如何应对变化
通过将变化封装在一层新的抽象中，实现了上层代码和变化的隔离，达到解耦的目的。对于工厂模式来说，新建的抽象叫做工厂，它将对象的构建和对象的使用分隔开，让使用对象的代码不依赖于构建对象的细节。
解耦的好处是：“当变化发生时上层代码不需要改动”，这句话也可以表达成：“在不修改既有代码的情况下扩展功能”。这就是著名的 “开闭原则” 。
- “对修改关闭”的意思是：当需要为类扩展功能时，不要想着去修改类的既有代码，这是不允许的！ 为啥不允许？因为既有代码是由数位程序员的努力，历经了多个版本的迭代，好不容易才得到的正确代码。其中蕴含着博大精深的知识，和你不曾了解的细节，修改它一定会出bug的！
- “对扩展开放”的意思是：类的代码应该具备良好的抽象，使得扩展类的时候，不需要修改类的既有代码。
现实的问题来了，如果项目中的既有类不具备扩展性，甚至是牵一发动全身的那种类。在一个时间较紧的迭代中需要往里添加新功能，你会怎么做？是违背“对修改关闭”，还是咬牙重构?（欢迎讨论~~）
3. 三种封装变化方式
- 简单工厂模式
既然目的是消除orderPizza()中构建具体pizza的细节，那最直接的做法是，将他们提取出来放到另一个类中：
public class PizzaFactory{ public static Pizza createPizza(String type){ Pizza pizza ; if(type.equals("cheese")){ pizza = new CheesePizza(); }else if(type.equals("bacon")){ pizza = new BaconPizza(); } return pizza ; }}复制代码 然后使用Pizza的代码就变成：
public class PizzaStore{ public Pizza orderPizza(String type){ Pizza pizza = PizzaFactory.createPizza(type); pizza.prepare(); pizza.bake(); return pizza ; }}复制代码 等等，这和我们平时将一段常用代码抽离出来放到Util类中有什么区别吗？
是的，没有任何区别。从严格意义上说，这不是一个设计模式，更像是一种编程习惯。虽然只是代码搬家，但这种习惯的好处是：它隐藏了构建对象的细节，因为构建对象是经常会发生变化的，所以它还封装了变化，最后它还可以被复用，比如菜单类也需要构建 pizza 对象并获取他们的价格。
使用静态方法是这类封装常用的技巧，它的好处是不需要新建工厂对象就可以实现调用，但缺点是不具备扩展性（静态方法不能被重写）。
- 工厂方法模式
简单工厂模式中，工厂能够构建几种对象是在编译之前就定义好的，如果想要新增另一种新对象，必须修改既有的工厂类。这不符合开闭原则。 所以简单工厂模式对于新增对象类型这个场景来说显得不够有弹性。
有没有办法不修改既有类就新增对象类型？
工厂方法模式就可以做到，因为它采用了继承：
//抽象pizza店public abstract class PizzaStore{ public Pizza orderPizza(String type){ Pizza pizza = createPizza(type); pizza.prepare(); pizza.bake(); return pizza ; } //不同地区的pizza店可以推出地方特色的pizza protected abstract Pizza createPizza(String type) ;}//A商店提供芝士和培根两种pizzapublic class PizzaStoreA extends PizzaStore{ @Override protected Pizza createPizza(String type){ Pizza pizza ; if(type.equals("cheese")){ pizza = new CheesePizza(); }else if(type.equals("bacon")){ pizza = new BaconPizza(); } return pizza ; }}复制代码 简单工厂模式将构建对象的细节封装在一个静态方法中（静态方法无法被继承），而工厂方法模式将其封装在一个抽象方法中，这样子类可以通过重写抽象方法新增 pizza。
现在是介绍另一个设计原则的绝佳时机，它就是 “依赖倒置原则” ：上层组件不能依赖下层组件，并且它们都不能依赖具体，而应该依赖抽象。
上面的例子中PizzaStore是上层组件，CheesePizza是下层组件，如果直接在PizzaStore中构建CheesePizza就违反了依赖倒置原则，经过工厂模式的重构，PizzaStore依赖于Pizza这个抽象，同时CheesePizza也依赖于这个抽象。所以违反依赖倒置会让代码缺乏弹性，不易扩展。
Android 中RecyclerView.Adapter就运用了工厂方法模式：
public abstract static class Adapter{ //封装了各式各样ViewHolder的构建细节，延迟实现构建细节到子类中 public abstract VH onCreateViewHolder(ViewGroup parent, int viewType);}复制代码
- 抽象工厂模式
如果需要构建一组对象怎么办？
抽象工厂模式用来处理这种情况，它将构建一组对象的细节封装在一个接口中：
//抽象原料工厂（原材料构建者）public interface IngredientFactory{ void Flour createFlour() ； void Sause createSause();}//原材料使用者public class Pizza{ private Flour flour; private Sause sause; //使用组合持有构建者 private IngredientFactory factory; //注入一个具体构建者 //同一种pizza，在不同地区可能会有不同口味 //那是因为虽然用的是同类原材料（抽象），当产地不同味道就不同（具体） public Pizza(IngredientFactory factory){ this.factory = factory; } //使用具体工厂构建原材料（发生多态的地方） public void prepare(){ flour = factory.createFlour(); sause = factory.createSause(); } public void bake(){} public void cut(){}}//具体工厂public class FactoryA implements IngredientFactory{ public Flour createFlour(){ return new FlourA(); } public Sause createSause(){ return new SauseA(); }}//构建pizza的时候传入具体工厂public class PizzaStoreA extends PizzaStore{ @Override protected Pizza createPizza(String type){ Pizza pizza ; FactoryA factory = new FactoryA(); if(type.equals("cheese")){ pizza = new CheesePizza(factory); }else if(type.equals("bacon")){ pizza = new BaconPizza(factory); } return pizza ; }}复制代码 如果地区B开了一家新pizza店，只需要新建FactoryB并在其中定义地区B原材料的构建方式，然后传入Pizza类，整个过程不需要修改Pizza基类。
抽象工厂模式 和 工厂方法模式 的区别在于：
- 前者适用于构建多个对象，并且使用组合。
- 后者适用于构建单个对象，并且使用继承。
策略模式
1. 变化是什么
对策略模式来说，变化就是一组行为，举个例子：
public class Robot{ public void onStart(){ goWorkAt9Am(); } public void onStop(){ goHomeAt9Pm(); }}复制代码 机器人每天早上9点工作。晚上9点回家。公司推出了两款新产品，一款早上8点开始工作，9点回家。另一款早上9点工作，10点回家。
面对这样的行为变化，继承是可以解决问题的，不过你需要新建两个Robot的子类，重载一个子类的onStart()，重载另一个子类的onStop()。如果每次行为变更都通过继承来解决，那子类的数量就会越来越多（膨胀的子类）。更重要的是，添加增子类是在编译时新增行为， 有没有办法可以在运行时动态的修改行为？
2. 如何应对变化
通过将变化的行为封装在接口中，就可以实现动态修改：
//抽象行为public interface Action{ void doOnStart(); void doOnStop();}public class Robot{ //使用组合持有抽象行为 private Action action; //动态改变行为 public void setAction(Action action){ this.action = action; } public void onStart(){ if(action!=null){ action.doOnStart(); } } public void onStop(){ if(action!=null){ action.doOnStop(); } }}//具体行为1public class Action1 implements Action{ public void doOnStart(){ goWorkAt8Am(); } public void doOnStop(){ goHomeAt9Pm(); }}//具体行为2public class Action2 implements Action{ public void doOnStart(){ goWorkAt9Am(); } public void doOnStop(){ goHomeAt10Pm(); }}//将具体行为注入行为使用者（运行时动态改变）public class Company{ public static void main(String[] args){ Robot robot1 = new Robot(); robot1.setAction(new Action1()); robot1.setAction(new Action2()); }}复制代码 策略模式将具体的行为和行为的使用者隔离，这样的好处是，当行为发生变化时，行为的使用者不需要变动。
Android 中的各种监听器都采用了策略模式，比如View.setOnClickListener()，但下面这个更偏向于观察者模式，他们的区别是策略模式的意图在于动态替换行为，当第二次调用setOnClickListener()时，之前的行为被替换，而观察者模式是动态添加观察者：
public class RecyclerView{ //使用组合持有抽象滚动行为 private List mScrollListeners; //抽象滚动行为 public abstract static class OnScrollListener { public void onScrollStateChanged(RecyclerView recyclerView, int newState){} public void onScrolled(RecyclerView recyclerView, int dx, int dy){} } //动态修改滚动行为 public void addOnScrollListener(OnScrollListener listener) { if (mScrollListeners == null) { mScrollListeners = new ArrayList<>(); } mScrollListeners.add(listener); } //使用滚动行为 void dispatchOnScrollStateChanged(int state) { if (mLayout != null) { mLayout.onScrollStateChanged(state); } onScrollStateChanged(state); if (mScrollListener != null) { mScrollListener.onScrollStateChanged(this, state); } if (mScrollListeners != null) { for (int i = mScrollListeners.size() - 1; i >= 0; i--) { mScrollListeners.get(i).onScrollStateChanged(this, state); } } }}复制代码 列表滚动后的行为各不相同，所以使用抽象类将其封装起来（其实和接口是一样的）。
策略模式的实战应用可以点击
模版方法模式
1. 变化是什么
从严格意义上讲，模版方法模式并不能套用开篇的那句话：“它们增加了一层抽象将变化封装起来，然后对抽象编程，并利用多态应对变化”。因为如果这样说，就是在强调目的是 “应对变化” 。但模版方法的目的更像是 “复用算法”，虽然它也有应对变化的成分。
对模版方法模式来说，变化就是算法的某个步骤，举个例子：
public class View{ public void draw(Canvas canvas) { ... // skip step 2 & 5 if possible (common case) if (!verticalEdges && !horizontalEdges) { // Step 3, draw the content if (!dirtyOpaque) onDraw(canvas); // Step 4, draw the children dispatchDraw(canvas); drawAutofilledHighlight(canvas); // Overlay is part of the content and draws beneath Foreground if (mOverlay != null && !mOverlay.isEmpty()) { mOverlay.getOverlayView().dispatchDraw(canvas); } // Step 6, draw decorations (foreground, scrollbars) onDrawForeground(canvas); // Step 7, draw the default focus highlight drawDefaultFocusHighlight(canvas); if (debugDraw()) { debugDrawFocus(canvas); } // we’re done... return; } ... } protected void dispatchDraw(Canvas canvas) { }}复制代码 节选了View.draw()方法中的某一片段，从注释中可以看出draw()定义了一个绘图的算法框架，一共有七个步骤，所有步骤都被抽象成一个方法，其中的变化在于，每个步骤对于不同类型的View都可能是不同的。所以为了让不同View复用这套算法框架，就把它定义在了父类中，子类可以通过重写某一个步骤来定义不同的行为。
模版方法模式一种常用的重构方法，它将子类的共用逻辑抽象到父类中，并将子类特有子逻辑设计成抽象方法供子类重写。
2. 对比
- 模版方法模式 vs 工厂方法模式
从代码层面看，模版方法的实现方式和工厂方法模式几乎一样，都是通过子类重写父类的方法。唯一的不同是，工厂方法模式父类中的方法必须是抽象的，也就是说强制子类实现，因为子类不实现父类就无法工作。而模版方法模式父类中的方法可以是不抽象的，也就是说子类可以不实现，父类照样能工作。这种在父类中空实现的方法有一个专门的名字叫 “hook（钩子）” ，钩子的存在，可以让子类有能力对算法的流程进行控制，比如ViewGroup.onInterceptTouchEvent()。
- 模版方法模式 vs 策略模式
从产出来看，模版方法模式和策略模式是一个阵营的，因为他们产出的都是一组行为（算法），而工厂模式产出的是一个对象。但它们俩对算法的控制力不同，策略模式可以轻松的替换掉整个算法，而模版方法模式只能替换掉算法中的某个步骤。从代码层面来看，它们的实现方式也不同，策略模式使用组合，而模版方法模式使用继承。组合比继承更具有弹性，因为它可以在运行时动态的替换行为。
后续
这个系列会持续分享对其他设计模式的理解。
《Head First》是一本让我对设计模式理解升级的书，强烈推荐（本篇中工厂模式的例子摘自其中）。