光氏饮品升级了 --- 工厂方法模式

前情提要

上集讲到, 小光的热干面店, 开始搭配提供饮料了. 再加上美女表妹的助阵, 生意是红红火火啊.

然而, 事情也不是尽善尽美的, 慢慢小光就听到了一些的客户的声音: 酸梅汤太酸了, 能调好点吗? 天冷了能来点热饮吗?

客户可是上帝啊, 小光立马就着手改进.

表妹的抱怨

带着客户的声音, 小光找表妹聊了下, 想让表妹修改下当前的酸梅汤泡制比例, 另外再增加一些热饮的泡制.

没想到, 表妹一听到着就很反对: "我现在已经记得太多了, 你这么不定时的修改, 增加, 我更容易记混, 到时候更出问题了". (职责太重)

小光一想, 是啊, 我把自己从做热干面添加各种配料的烦恼中释放出来了(通过Builder模式). 不能让表妹也陷入这样的烦恼啊.

解决之路

可是怎么才能更好的解决这个问题呢?
要是我有很多个表妹就好了, 每个表妹负责一种饮料的泡制, 小光想着. 嗯~, 很多个表妹?! 小光微微一笑, 计上心头.

小光买来很多个迷你饮水机, 一个装一种饮料, 并且贴上相应的标签, 如此这般:

每个迷你饮水机作为一个饮料机, 用来生产不同的饮料. 表妹只有根据用户的需求选择不同的饮料机打出饮料即可.

这样, 表妹也无需关注饮料的生产过程了, 不用记那么多的饮料配置方式了. 如果想要新增饮品, 再弄一台饮料机就行了.

来看看对应关系

这是没有标签的饮水机(饮料机):

public interface IBeverageMachine {

    Drink makeDrink();
}

这是贴了不同饮料类型的饮料机:

public class OrangeJuiceMachine implements IBeverageMachine {
    @Override
    public Drink makeDrink() {
        return new OrangeJuice().make();
    }
}

public class CokeMachine implements IBeverageMachine {
    @Override
    public Drink makeDrink() {
        return new Coke().make();
    }
}

public class PlumJuiceMachine implements IBeverageMachine {
    @Override
    public Drink makeDrink() {
        return new PlumJuice().make();
    }
}

这是那些饮料(还是有一个抽象继承关系):

public abstract class Drink {

    private String name;
    private String instantPackage;

    public Drink make() {
        this.name = getName();
        this.instantPackage = getInstantPackage();
        return this;
    }

    abstract String getInstantPackage();
    abstract String getName();

    @Override
    public String toString() {
        return "This is a cup of:" + this.name;
    }
}

public class Coke extends Drink {
    @Override
    String getInstantPackage() {
        return "速溶可乐粉";
    }

    @Override
    String getName() {
        return "可乐";
    }
}

public class OrangeJuice extends Drink {
    @Override
    String getInstantPackage() {
        return "速溶橙汁粉";
    }

    @Override
    String getName() {
        return "橙汁";
    }
}

public class PlumJuice extends Drink {
    @Override
    String getInstantPackage() {
        return "速溶酸梅粉";
    }

    @Override
    String getName() {
        return "酸梅汤";
    }
}

相比上一篇简单工厂中的饮料, 我们将打包这个操作从饮料这个对象中移除了, 目前的饮料对象中只是一些简单的属性.
为什么要这么做呢? 大家可以用自己面向对象编程思想的脑洞自由发挥下, 下期说说我的想法.

现在表妹的工作就变得简单了:

public class Cousins {

    private IBeverageMachine mBeverageMachine;

    private void setBeverageMachine(IBeverageMachine machine) {
        this.mBeverageMachine = machine;
    }

    private Drink takeDrink() {
        if (mBeverageMachine == null) throw new NullPointerException("Should set Beverage Machine firstly.");

        return mBeverageMachine.makeDrink();
    }

    public static void main(String[] args) {

        Cousins cousins = new Cousins();

        // for A
        cousins.setBeverageMachine(new OrangeJuiceMachine());
        Drink drink = cousins.takeDrink();
        System.out.println(drink);

        // for B
        cousins.setBeverageMachine(new CokeMachine());
        System.out.println(cousins.takeDrink());
    }
}

当A要橙汁时, 表妹去OrangeJuiceMachine装一杯, 当B需要可乐时, 表妹再去CokeMachine拿:

This is a cup of:橙汁
This is a cup of:可乐

表妹的工作变得更简单了, 工作效率也更高了, 也更能微笑面对顾客了, 哈哈...

想要奶茶的C顾客

这天, 来了一位顾客D, 问: "老板, 有没有热奶茶啊?". 考验小光的程序的时候到了. 很快, 小光copy出了一个奶茶机(扩展开放), 同时也无需修改原来的那些个饮料机程序(修改关闭), 不会因此而耽误生意.

新增奶茶饮料:

public class MilkTea extends Drink {
    @Override
    String getInstantPackage() {
        return "速溶奶茶粉";
    }

    @Override
    String getName() {
        return "奶茶";
    }
}

奶茶机:

public class MilkTeaMachine implements IBeverageMachine {
    @Override
    public Drink makeDrink() {
        return new MilkTea().make();
    }
}

现在的台面:

表妹的工作也很简单, 去奶茶机那儿接奶茶就是了:

// for D
cousins.setBeverageMachine(new MilkTeaMachine());
System.out.println(cousins.takeDrink());

D拿到的:

This is a cup of:奶茶

故事之后

照例, 我们先来画出现在的类对应关系:

实际上这个就是工厂方法模式.

几个点:
1, 为何叫工厂方法, 是因为每个工厂有一个方法来创建产品.
2, 每个产品对应一个工厂实例来生产这个产品实例.
3, 因为产品和其对应的工厂都与其他产品分离, 我们可以很轻易的去增加新的产品和其对应的工厂, 而不改变原来的结构. (开闭原则, 实际上还蕴含了职责单一)

扩展阅读

工厂方法模式如同Buidler模式, 是一些开源库中非常常见的用来创建实例的设计模式.

例如OkHttp中ModelLoader相关的实现:

看对应关系就跟清晰了, 就不一一类比了.

小光看着这一排饮料机, 成就感悠然而生, 仿佛又回到了那个彻夜编码的岁月.