据说这些设计模式的理念都是相同的！

点击上方 "程序员小乐" ，关注公众号

8点20分，第一时间与你相约

每日英文

Sometimes, I’d rather feel nothing. It’s better. It’s easier.

有时候我真希望自己没有感觉，那就好过得多了。

每日掏心话

也许时间会夺去你那令人妒忌的容颜，却无法抢走我爱你坚定的信念，因为我有一种无穷而又温柔的力量，它就是一心一意!

来自：唐子玄 | 责编：乐乐

链接：juejin.im/user/5771d75d2e958a0078f97976

图片来自网络

   01 开始   

虽然不同的设计模式解决的问题各不相同，但从一个更高的抽象层次来看，它们通过相同的手段来实现相同的目的。本文将以更抽象的视角剖析工厂模式、策略模式、模版方法模式，以及这些模式所遵循的设计原则。先用一句话总结它们的共同点：

它们增加了一层抽象将变化封装起来，然后对抽象编程，并利用多态应对变化。

   02 工厂模式   

变化是什么

对工厂模式来说，变化就是构建对象的方式，举个例子：

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。

如何应对变化

通过将变化封装在一层新的抽象中，实现了上层代码和变化的隔离，达到解耦的目的。对于工厂模式来说，新建的抽象叫做工厂，它将对象的构建和对象的使用分隔开，让使用对象的代码不依赖于构建对象的细节。

解耦的好处是：“当变化发生时上层代码不需要改动”，这句话也可以表达成：“在不修改既有代码的情况下扩展功能”。这就是著名的 “开闭原则” 。

• “对修改关闭”的意思是：当需要为类扩展功能时，不要想着去修改类的既有代码，这是不允许的！ 为啥不允许？因为既有代码是由数位程序员的努力，历经了多个版本的迭代，好不容易才得到的正确代码。其中蕴含着博大精深的知识，和你不曾了解的细节，修改它一定会出bug的！

• “对扩展开放”的意思是：类的代码应该具备良好的抽象，使得扩展类的时候，不需要修改类的既有代码。

现实的问题来了，如果项目中的既有类不具备扩展性，甚至是牵一发动全身的那种类。在一个时间较紧的迭代中需要往里添加新功能，你会怎么做？是违背“对修改关闭”，还是咬牙重构?（欢迎讨论~~）

三种封装变化方式

1.简单工厂模式

既然目的是消除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 对象并获取他们的价格。

使用静态方法是这类封装常用的技巧，它的好处是不需要新建工厂对象就可以实现调用，但缺点是不具备扩展性（静态方法不能被重写）。

2.工厂方法模式

简单工厂模式中，工厂能够构建几种对象是在编译之前就定义好的，如果想要新增另一种新对象，必须修改既有的工厂类。这不符合开闭原则。 所以简单工厂模式对于新增对象类型这个场景来说显得不够有弹性。

有没有办法不修改既有类就新增对象类型？

工厂方法模式就可以做到，因为它采用了继承：

//抽象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商店提供芝士和培根两种pizza
public 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<VH extends ViewHolder> {
    //封装了各式各样ViewHolder的构建细节，延迟实现构建细节到子类中
    public abstract VH onCreateViewHolder(ViewGroup parent, int viewType);
}

3.抽象工厂模式

如果需要构建一组对象怎么办？

抽象工厂模式用来处理这种情况，它将构建一组对象的细节封装在一个接口中：

//抽象原料工厂（原材料构建者）
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. 前者适用于构建多个对象，并且使用组合。

2. 后者适用于构建单个对象，并且使用继承。

   03 策略模式   

变化是什么

对策略模式来说，变化就是一组行为，举个例子：

public class Robot{
    public void onStart(){
        goWorkAt9Am();
    }
    public void onStop(){
        goHomeAt9Pm();
    }
}

机器人每天早上9点工作。晚上9点回家。公司推出了两款新产品，一款早上8点开始工作，9点回家。另一款早上9点工作，10点回家。

面对这样的行为变化，继承是可以解决问题的，不过你需要新建两个Robot的子类，重载一个子类的onStart()，重载另一个子类的onStop()。如果每次行为变更都通过继承来解决，那子类的数量就会越来越多（膨胀的子类）。更重要的是，添加增子类是在编译时新增行为， 有没有办法可以在运行时动态的修改行为？

如何应对变化

通过将变化的行为封装在接口中，就可以实现动态修改：

//抽象行为
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();
        }
    }
}

//具体行为1
public class Action1 implements Action{
    public void doOnStart(){
        goWorkAt8Am();
    }
    public void doOnStop(){
        goHomeAt9Pm();
    }
}

//具体行为2
public 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(robot1);
        Robot robot2 = new Robot();
        robot2.setAction(robot2);
    }
}

策略模式将具体的行为和行为的使用者隔离，这样的好处是，当行为发生变化时，行为的使用者不需要变动。

Android 中的各种监听器都采用了策略模式，比如：

public class RecyclerView{
    //使用组合持有抽象滚动行为
    private List<OnScrollListener> 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);
            }
        }
    }
}

列表滚动后的行为各不相同，所以使用抽象类将其封装起来（其实和接口是一样的）。

策略模式的实战应用可以点击这里

https://juejin.im/post/5ce0e55ae51d451075366eeb

   04 模版方法模式   

变化是什么

从严格意义上讲，模版方法模式并不能套用开篇的那句话：“它们增加了一层抽象将变化封装起来，然后对抽象编程，并利用多态应对变化”。因为如果这样说，就是在强调目的是 “应对变化” 。但模版方法的目的更像是 “复用算法”，虽然它也有应对变化的成分。

对模版方法模式来说，变化就是算法的某个步骤，举个例子：

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复用这套算法框架，就把它定义在了父类中，子类可以通过重写某一个步骤来定义不同的行为。

模版方法模式一种常用的重构方法，它将子类的共用逻辑抽象到父类中，并将子类特有子逻辑设计成抽象方法供子类重写。

对比

模版方法模式 vs 工厂方法模式

从代码层面看，模版方法的实现方式和工厂方法模式几乎一样，都是通过子类重写父类的方法。唯一的不同是，工厂方法模式父类中的方法必须是抽象的，也就是说强制子类实现，因为子类不实现父类就无法工作。而模版方法模式父类中的方法可以是不抽象的，也就是说子类可以不实现，父类照样能工作。这种在父类中空实现的方法有一个专门的名字叫 “hook（钩子）” ，钩子的存在，可以让子类有能力对算法的流程进行控制，比如ViewGroup.onInterceptTouchEvent()。

模版方法模式 vs 策略模式

从产出来看，模版方法模式和策略模式是一个阵营的，因为他们产出的都是一组行为（算法），而工厂模式产出的是一个对象。但它们俩对算法的控制力不同，策略模式可以轻松的替换掉整个算法，而模版方法模式只能替换掉算法中的某个步骤。从代码层面来看，它们的实现方式也不同，策略模式使用组合，而模版方法模式使用继承。组合比继承更具有弹性，因为它可以在运行时动态的替换行为。

   05 后续   

《Head First》是一本让我对设计模式理解升级的书，强烈推荐（本篇中工厂模式的例子摘自其中）。

欢迎在留言区留下你的观点，一起讨论提高。如果今天的文章让你有新的启发，学习能力的提升上有新的认识，欢迎转发分享给更多人。

欢迎各位读者加入程序员小乐技术群，在公众号后台回复“加群”或者“学习”即可。

猜你还想看

阿里、腾讯、百度、华为、京东最新面试题汇集

当我们遇到100亿次请求？该如何设计后端架构？

高中就开始学的正态分布，原来如此重要

一个合格的技术面试官是怎么样的？

百度地震了，也许早晚的事

Google 程序员有哪些高效的编程习惯？

关注「程序员小乐」，收看更多精彩内容