前情提要

本意是想像美剧的previously那样, 不知道怎么翻译好, 求翻译达人赐教…
上集讲到, 小光辞了工作, 开起了热干面的店子, 用Builder模式改造了热干面的构建过程, 是日渐稳定有效起来, 生意也是越来越好.
但是小光是善于观察的同学啊, 他发现热干面真的好干啊(好像一般人也都能发现, 鬼脸~). 心想, 解决用户痛点才产品的存在根本啊, 是时候推出新东西了.
于是他决定跟推出自己的光氏饮料产品.

饮料的制作

经过一番调查和走访, 小光发现几个特点:
大家对这个饮料要求不高(码农的屌丝特性啊) , 解渴为主.
因为赶着上班, 一般要求要快, 最好可以直接拿走.
品种要丰富, 大家口味不一啊.
于是, 小光选用了最新的XX牌 (有广告商找我吗? 哈哈.) 速溶饮料. 制作饮料的过程很简单, 很快, 小光做出了第一杯饮料—-橙汁:

public class OrangeJuice {
    public void make() {
        // 1. 拿出一次性饮料杯
        System.out.println("拿出一次性饮料杯");
        // 2. 加入速溶橙汁粉
        System.out.println("加入速溶橙汁粉");
        // 3. 加水冲兑
        System.out.println("加水");
        // 4. 加盖, 打包
        System.out.println("加盖, 打包");
    }
}

小光的思考

看起来, 程序似乎是可以运转了, 让我们投入生产吧…
然而, 小光何许人啊, 毕竟是在码农界混了好些年的同志啊. 还没有投入使用, 就发现了”问题”:
饮料有很多种, 过程都类似, 只是放的速溶包不一样. 如果我每个都这么写, 改天真有人找我打广告, 杯子上印个二维码什么的, 我不是每个饮料的制作过程都要改啊
灵光一现, 小光想起了面向对象思想中提到的抽象, 封装, 于是乎, 小光改写了自己的程序:
他抽象出来一个”Drink”类:

public abstract class Drink {

    public void make() {
        // 1. 拿出一次性饮料杯
        System.out.println("拿出一次性饮料杯");
        // 2. 加入速溶橙汁粉
        System.out.println("加入" + getInstantPackage());
        // 3. 加水冲兑
        System.out.println("加水");
        // 4. 加盖, 打包
        System.out.println("加盖, 打包");
    }

    abstract String getInstantPackage();
}

可乐, 酸梅汤, 橙汁皆继承了Drink:

public class Coke extends Drink {
    @Override
    String getInstantPackage() {
        return "速溶可乐粉";
    }
}
public class PlumJuice extends Drink {
    @Override
    String getInstantPackage() {
        return "速溶酸梅粉";
    }
}
public class OrangeJuice extends Drink {
    @Override
    String getInstantPackage() {
        return "速溶橙汁粉";
    }
}

开卖

制作完饮料, 准备开卖了, 是这样的:

public class XiaoGuang {
    public static void main(String[] args) {
        OrangeJuice orangeJuice = new OrangeJuice();
        orangeJuice.make();
    }
}

第二天, 生意实在太好, 小光请了表妹临时来帮忙泡制饮料. 而且, 小光还发现自己也无需关注用户要什么饮料了, 直接让用户告诉表妹, 表妹直接制作饮料给用户就行~
表妹负责根据用户要求生产饮料:

public class Cousins {

    public static Drink create(String drinkType) {
        //  Java7开始, switch支持String
        switch (drinkType) {
            case "橙汁":
                return new OrangeJuice();
            case "酸梅汤":
                return new PlumJuice();
            case "可乐":
                return new Coke();
            default:
                return new OrangeJuice();
        }
    }
}

小光不再关注饮料具体种类:

public class XiaoGuang {
    public static void main(String[] args) {
        Drink drink = Cousins.create("可乐");
        drink.make();
    }
}

加上饮料套餐之后, 生意果然越来越好, 估计也有美女助阵的加成, 哈哈…

故事之后

可能有些同学已经看出一点熟悉感了, 我们把这些关系一个UML表示下:
~

如此, 应该就比较清晰了, 这个就是我们今天的主题—-简单工厂.
严格来说, 简单工厂并非一种设计模式, 可以说是一种编码习惯.
那么我们为什么要使用简单工厂, 或者说这么做有什么好处呢?
从我们这个例子中, 可以看到, 小光(Client类)不需要去关注饮料泡制(Drink make)这个过程了, 有更多的时间去接待客户, 只需从表妹(工厂类)那拿到相应的饮料给客户即可.
这个其实是蕴含了单一职责的编程思想:
小光的职责是接待客户
表妹的职责是泡制饮料
简单工厂一般来说, 使用一个静态方法来生产产品, 故而有时也称之为静态工厂方法模式.

扩展阅读

在这个故事的过程中, 我们提到了面向对象的抽象, 封装特性. 实际上我们所有的OOD原则, 设计模式, 都是基于面向对象的思想的, 离不开抽象, 封装, 继承, 多态几大特性. 随着对这些设计模式的分析, 也可以让我们加深面向对象的编程思想.
以Glide为例, 其中的DefaultConnectivityMonitorFactory.java就是一个类似的简单工厂实现:

public class DefaultConnectivityMonitorFactory implements   ConnectivityMonitorFactory {

  @NonNull
  public ConnectivityMonitor build(
      @NonNull 
      Context context,
      @NonNull 
      ConnectivityMonitor.ConnectivityListener listener) {
        final int res = context.checkCallingOrSelfPermission("android.permission.ACCESS_NETWORK_STATE");
        final boolean hasPermission = res == PackageManager.PERMISSION_GRANTED;
        if (hasPermission) {
            return new DefaultConnectivityMonitor(context, listener);
        } else {
            return new NullConnectivityMonitor();
        }
  }
}

与表妹Cousins(工厂)的实现很类似, 只是这个Factory具体创建什么产品不是由传入的参数决定的, 是在内部的逻辑决定的.
转化为类图关系, 更加清晰: