前情提要
本意是想像美剧的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具体创建什么产品不是由传入的参数决定的, 是在内部的逻辑决定的.
转化为类图关系, 更加清晰:
一直在说的话: 所谓架构, 设计模式都是一种思想, 没有固定的招式, 所有的这些招式都是让我们入门, 了解面向对象的基础思想, 然后能运用无形. 共勉.
留个尾子
大家可能有发现, 简单工厂的弊端也是很多的, 表妹(工厂)的责任太重, 包含(UML依赖关系)了所有的具体产品的实现. 另外, 如果需要修改或增加产品, 我们就得改变工厂类的实现. 这显然违反了开闭原则.
故而, 简单工厂, 一般来说, 适用于产品类别较少, 且固定的场景.
