工厂模式·抽象工厂——理解“开放封闭”
上一节提到工厂模式中的简单工厂，这节开始理解抽象工厂。
1、从一个不简单的简单工厂开始
在实际的业务中，我们往往面对的复杂度并非数个类、一个工厂可以解决，而是需要动用多个工厂。
我们来看一个简单工厂函数：
function Factory(name, age, career) {
let work
switch (career) {
case 'coder':
work = ['写代码', '修Bug']
break
case 'product manager':
work = ['写PRD', '催更']
break
case 'boss':
work = ['喝茶', '看报']
case 'xxx':
// 其它工种的职责分配
...
return new User(name, age, career, work)
}
乍一看没什么问题，但是经不起推敲呀。
首先，我们把 Boss 这个角色和普通员工塞进了一个工厂。
我们知道，Boss 和基层员工在职能上是有差别的，例如权限。
有一些系统，比如员工绩效评估的打分入口，就只有 Boss 点得进去，除此之外还有许多操作只有 Boss 可执行，因此我们需要对 Boss 的对象进行单独的逻辑处理。
怎么处理？去修改 Factory 的函数体、增加 Boss 相关的判断和处理逻辑吗？
单从功能实现上来说，没问题。
但这么做其实是在挖坑——因为公司不仅仅只有这两类人，还有外包同学、保安等，他们的权限、职能也和基层员工不一样。
如果延续这个思路，每考虑到一个新的员工群体，就回去修改一次 Factory 的函数体，这样做糟糕透了——没有遵守开放封闭原则。
开放封闭原则的内容：对拓展开放，对修改封闭
开放封闭原则说得更准确点，就是软件实体（类、模块、函数）可以扩展，但是不可修改。以上对 Boss 单独逻辑处理就错在我们不是在拓展，而是在修改。
2、抽象工厂模式
先来看这么一个示例：
我们知道手机的基本组成是操作系统（OS）和硬件（HardWare）。
如果我要开一个手机工厂，那需要准备好操作系统和硬件，才能实现手机的量产。
现在我还不知道下一个生产线要生产一台什么样的手机，只知道要有这两部分组成，所以可以用一个抽象类来约定住这台手机的组成：
class MobilePhoneFactory {
// 提供操作系统的接口
createOS() {
throw new Error("抽象工厂方法不允许直接调用，你需要将我重写！");
}
// 提供硬件的接口
createHardWare() {
throw new Error("抽象工厂方法不允许直接调用，你需要将我重写！");
}
}
上面这个类，除了约定手机流水线的通用能力之外，啥也不干。
如果你尝试让它干点啥，比如 new 一个 MobilePhoneFactory 实例，并尝试调用它的实例方法，它还报错，并提醒你“阿 Sir，我不是让你拿去 new 一个实例的，我就是个定规矩的”。
在抽象工厂模式里，上面这个类就是我们食物链顶端最大的 Boss——AbstractFactory（抽象工厂）。
抽象工厂不干活，具体工厂（ConcreteFactory）来干活！
当我们明确了生产方案，明确某一条手机生产流水线具体要生产什么样的手机了之后，就可以化抽象为具体。
比如我现在想要一个专门生产 Android 系统 + 高通硬件的手机的生产线，并给手机型号起名叫 UPhone，那我就可以为 UPhone 定制一个具体工厂：
// 具体工厂继承自抽象工厂
class UPhoneFactory extends MobilePhoneFactory {
createOS() {
// 提供安卓系统实例
return new AndroidOS();
}
createHardWare() {
// 提供高通硬件实例
return new QualcommHardWare();
}
}
这里我们在提供安卓系统的时候，调用了两个构造函数：AndroidOS 和 QualcommHardWare，它们分别用于生成具体的操作系统和硬件实例。
像这种被我们拿来用于 new 出具体对象的类，叫做具体产品类（ConcreteProduct）。
具体产品类往往不会孤立存在，不同的具体产品类往往有着共同的功能。
比如安卓系统类和苹果系统类，它们都是操作系统，都有着可以操控手机硬件系统这样一个最基本的功能。
因此我们可以用一个抽象产品（AbstractProduct）类来声明这一类产品应该具有的基本功能：
// 定义操作系统这类产品的抽象产品类
class OS {
controlHardWare() {
throw new Error('抽象产品方法不允许直接调用，你需要将我重写！');
}
}
// 定义具体操作系统的具体产品类
class AndroidOS extends OS {
controlHardWare() {
console.log('我会用安卓的方式去操作硬件')
}
}
class AppleOS extends OS {
controlHardWare() {
console.log('我会用苹果的方式去操作硬件')
}
}
...
硬件类产品同理：
// 定义手机硬件这类产品的抽象产品类
class HardWare {
// 手机硬件的共性方法，这里提取了“根据命令运转”这个共性
operateByOrder() {
throw new Error('抽象产品方法不允许直接调用，你需要将我重写！');
}
}
// 定义具体硬件的具体产品类
class QualcommHardWare extends HardWare {
operateByOrder() {
console.log('我会用高通的方式去运转')
}
}
class MiWare extends HardWare {
operateByOrder() {
console.log('我会用小米的方式去运转')
}
}
...
这样一来，当我们需要生产一台 UPhone 手机时，我们只需要这样做：
// 这是我的手机
const myPhone = new UPhoneFactory();
// 让它拥有操作系统
const myOS = myPhone.createOS();
// 让它拥有硬件
const myHardWare = myPhone.createHardWare();
// 启动操作系统 (输出‘我会用安卓的方式去操作硬件’)
myOS.controlHardWare();
// 唤醒硬件 (输出‘我会用高通的方式去运转’)
myHardWare.operateByOrder();
假如有一天，Uphone 过气了，我们就不需要对抽象工厂 MobilePhoneFactory 做任何修改，只需要拓展它的种类：
class UPhoneFactory extends MobilePhoneFactory {
createOS() {
// 操作系统实现代码
}
createHardWare() {
// 硬件实现代码
}
}
这个操作对原有的系统不会造成任何潜在影响，所谓的“对拓展开放，对修改封闭”就这么圆满实现了。
3、总结
回头对比一下简单工厂和抽象工厂的思路，可以知道：
相同点在于二者都尝试去分离一个系统中变与不变的部分。
不同点在于场景的复杂度：
在简单工厂的使用场景里，处理的对象是类，并且是一些非常好对付的类——它们的共性容易抽离，同时因为逻辑本身比较简单，故而不苛求代码可扩展性。
抽象工厂本质上处理的其实也是类，但是是一帮非常棘手、繁杂的类，这些类中不仅能划分出门派，还能划分出等级，同时存在着千变万化的扩展可能性——这使得我们必须对共性作更特别的处理、使用抽象类去降低扩展的成本，同时需要对类的性质作划分，于是有了这样的四个关键角色：
① 抽象工厂（抽象类，不能被用于生成具体实例）
用于声明最终目标产品的共性。
在一个系统里，抽象工厂可以有多个，每个抽象工厂对应的这类产品，被称为“产品族”。
② 具体工厂（用于生成产品族里的一个具体的产品）
继承自抽象工厂、实现了抽象工厂里声明的那些方法，用于创建具体产品的类。
③ 抽象产品（抽象类，不能被用于生成具体实例）
上面我们看到，具体工厂里实现的接口，会依赖一些类，这些类对应到各种各样的具体的细粒度产品（比如操作系统、硬件等），这些具体产品类的共性各自抽离，便对应到了各自的抽象产品类。
④ 具体产品（用于生成产品族中的一个具体产品所依赖的更细粒度产品）
比如我们上文中具体的一种操作系统、或具体的一种硬件等。
抽象工厂模式的定义，是围绕一个超级工厂创建其他工厂。
抽象工厂目前来说在 JS 世界里也应用得并不广泛，所以大家不必拘泥于细节，只需留意以下三点：
- 学会用 ES6 模拟 JAVA 中的抽象类；
- 了解抽象工厂模式中四个角色的定位与作用；
- 对“开放封闭原则”形成自己的理解，知道它好在哪，知道执行它的必要性。