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

前情提要

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

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

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

所有示例源码已经上传到Github, 戳这里

表妹的抱怨

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

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

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

解决之路

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

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

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

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

来看看对应关系

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

1
2
3
4
public interface IBeverageMachine {
Drink makeDrink();
}

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
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();
}
}

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
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 "酸梅汤";
}
}

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
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拿:

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

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

想要奶茶的C顾客

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

新增奶茶饮料:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public class MilkTea extends Drink {
@Override
String getInstantPackage() {
return "速溶奶茶粉";
}
@Override
String getName() {
return "奶茶";
}
}
````
**奶茶机:**
````java
public class MilkTeaMachine implements IBeverageMachine {
@Override
public Drink makeDrink() {
return new MilkTea().make();
}
}

现在的台面:

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

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

D拿到的:

1
This is a cup of:奶茶

故事之后

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

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

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

扩展阅读

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

例如OkHttp中ModelLoader相关的实现:

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

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