一个不简单的简单工厂引发的命案

在实际的业务中，我们往往面对的复杂度并非数个类、一个工厂可以解决，而是需要动用多个工厂。
我们继续看上个小节举出的例子，简单工厂函数最后长这样：

  1. function Factory(name, age, career) {
  2.     let work
  3.     switch(career) {
  4.         case 'coder':
  5.             work =  ['写代码','写系分', '修Bug'] 
  6.             break
  7.         case 'product manager':
  8.             work = ['订会议室', '写PRD', '催更']
  9.             break
  10.         case 'boss':
  11.             work = ['喝茶', '看报', '见客户']
  12.         case 'xxx':
  13.             // 其它工种的职责分配
  14.             ...
  16.     return new User(name, age, career, work)
  17. }

乍一看没什么问题，但是经不起推敲呀。首先映入眼帘的 Bug，是我们把 Boss 这个角色和普通员工塞进了一个工厂。大家知道，Boss 和基层员工在职能上差别还是挺大的，具体在员工系统里怎么表现呢？首先他的权限就跟咱们不一样。有一些系统，比如员工绩效评估的打分入口，就只有 Boss 点得进去，对不对？除此之外还有许多操作，是只有管理层可以执行的，因此我们需要对这个群体的对象进行单独的逻辑处理。
怎么办？去修改 Factory 的函数体、增加管理层相关的判断和处理逻辑吗？单从功能实现上来说，没问题。但这么做其实是在挖坑——因为公司不仅仅只有这两类人，除此之外还有外包同学、还有保安，他们的权限、职能都存在着质的差别。如果延续这个思路，每考虑到一个新的员工群体，就回去修改一次 Factory 的函数体，这样做糟糕透了——首先，是Factory会变得异常庞大，庞大到你每次添加的时候都不敢下手，生怕自己万一写出一个Bug，就会导致整个Factory的崩坏，进而摧毁整个系统；其次，你坑死了你的队友：Factory 的逻辑过于繁杂和混乱，没人敢维护它；最后，你还连带坑了隔壁的测试同学：你每次新加一个工种，他都不得不对整个Factory 的逻辑进行回归——谁让你的改变是在 Factory 内部原地发生的呢！这一切悲剧的根源只有一个——没有遵守开放封闭原则。
我们再复习一下开放封闭原则的内容：对拓展开放，对修改封闭。说得更准确点，软件实体（类、模块、函数）可以扩展，但是不可修改。楼上这波操作错就错在我们不是在拓展，而是在疯狂地修改。

抽象工厂模式

上面这段可能仍有部分同学觉得抽象，也没关系。这里咱们先不急着理解透彻这个干巴巴的概念，先来看这么一个示例：
大家知道一部智能手机的基本组成是操作系统（Operating System，我们下面缩写作 OS）和硬件（HardWare）组成。所以说如果我要开一个山寨手机工厂，那我这个工厂里必须是既准备好了操作系统，也准备好了硬件，才能实现手机的量产。考虑到操作系统和硬件这两样东西背后也存在不同的厂商，而我现在并不知道我下一个生产线到底具体想生产一台什么样的手机，我只知道手机必须有这两部分组成，所以我先来一个抽象类来约定住这台手机的基本组成：

  1. class MobilePhoneFactory {
  2.     // 提供操作系统的接口
  3.     createOS(){
  4.         throw new Error("抽象工厂方法不允许直接调用，你需要将我重写！");
  5.     }
  6.     // 提供硬件的接口
  7.     createHardWare(){
  8.         throw new Error("抽象工厂方法不允许直接调用，你需要将我重写！");
  9.     }
  10. }

楼上这个类，除了约定手机流水线的通用能力之外，啥也不干。如果你尝试让它干点啥，比如 new 一个 MobilePhoneFactory 实例，并尝试调用它的实例方法。它还会给你报错，提醒你“我不是让你拿去new一个实例的，我就是个定规矩的”。在抽象工厂模式里，楼上这个类就是我们食物链顶端最大的 Boss——AbstractFactory（抽象工厂）。
抽象工厂不干活，具体工厂（ConcreteFactory）来干活！当我们明确了生产方案，明确某一条手机生产流水线具体要生产什么样的手机了之后，就可以化抽象为具体，比如我现在想要一个专门生产 Android 系统 + 高通硬件的手机的生产线，我给这类手机型号起名叫 FakeStar，那我就可以为 FakeStar 定制一个具体工厂：

  1. // 具体工厂继承自抽象工厂
  2. class FakeStarFactory extends MobilePhoneFactory {
  3.     createOS() {
  4.         // 提供安卓系统实例
  5.         return new AndroidOS()
  6.     }
  7.     createHardWare() {
  8.         // 提供高通硬件实例
  9.         return new QualcommHardWare()
  10.     }
  11. }

这里我们在提供安卓系统的时候，调用了两个构造函数：AndroidOS 和 QualcommHardWare，它们分别用于生成具体的操作系统和硬件实例。像这种被我们拿来用于 new 出具体对象的类，叫做具体产品类（ConcreteProduct）。具体产品类往往不会孤立存在，不同的具体产品类往往有着共同的功能，比如安卓系统类和苹果系统类，它们都是操作系统，都有着可以操控手机硬件系统这样一个最基本的功能。因此我们可以用一个抽象产品（AbstractProduct）类来声明这一类产品应该具有的基本功能（众：什么抽象产品？？？要这些玩意儿干啥？老夫写代码就是一把梭，为啥不让我老老实实一个一个写具体类？？？大家稍安勿躁，先把例子看完，下文会有解释）

  1. // 定义操作系统这类产品的抽象产品类
  2. class OS {
  3.     controlHardWare() {
  4.         throw new Error('抽象产品方法不允许直接调用，你需要将我重写！');
  5.     }
  6. }
  8. // 定义具体操作系统的具体产品类
  9. class AndroidOS extends OS {
  10.     controlHardWare() {
  11.         console.log('我会用安卓的方式去操作硬件')
  12.     }
  13. }
  15. class AppleOS extends OS {
  16.     controlHardWare() {
  17.         console.log('我会用🍎的方式去操作硬件')
  18.     }
  19. }
  20. ...

硬件类产品同理：

  1. // 定义手机硬件这类产品的抽象产品类
  2. class HardWare {
  3.     // 手机硬件的共性方法，这里提取了“根据命令运转”这个共性
  4.     operateByOrder() {
  5.         throw new Error('抽象产品方法不允许直接调用，你需要将我重写！');
  6.     }
  7. }
  9. // 定义具体硬件的具体产品类
  10. class QualcommHardWare extends HardWare {
  11.     operateByOrder() {
  12.         console.log('我会用高通的方式去运转')
  13.     }
  14. }
  16. class MiWare extends HardWare {
  17.     operateByOrder() {
  18.         console.log('我会用小米的方式去运转')
  19.     }
  20. }
  21. ...

好了，如此一来，当我们需要生产一台FakeStar手机时，我们只需要这样做：

  1. // 这是我的手机
  2. const myPhone = new FakeStarFactory()
  3. // 让它拥有操作系统
  4. const myOS = myPhone.createOS()
  5. // 让它拥有硬件
  6. const myHardWare = myPhone.createHardWare()
  7. // 启动操作系统(输出‘我会用安卓的方式去操作硬件’)
  8. myOS.controlHardWare()
  9. // 唤醒硬件(输出‘我会用高通的方式去运转’)
  10. myHardWare.operateByOrder()

关键的时刻来了——假如有一天，FakeStar过气了，我们需要产出一款新机投入市场，这时候怎么办？我们是不是不需要对抽象工厂MobilePhoneFactory做任何修改，只需要拓展它的种类：

  1. class newStarFactory extends MobilePhoneFactory {
  2.     createOS() {
  3.         // 操作系统实现代码
  4.     }
  5.     createHardWare() {
  6.         // 硬件实现代码
  7.     }
  8. }

这么个操作，对原有的系统不会造成任何潜在影响 所谓的“对拓展开放，对修改封闭”就这么圆满实现了。前面我们之所以要实现抽象产品类，也是同样的道理。

总结

大家现在回头对比一下抽象工厂和简单工厂的思路，思考一下：它们之间有哪些异同？
它们的共同点，在于都尝试去分离一个系统中变与不变的部分。它们的不同在于场景的复杂度。在简单工厂的使用场景里，处理的对象是类，并且是一些非常好对付的类——它们的共性容易抽离，同时因为逻辑本身比较简单，故而不苛求代码可扩展性。抽象工厂本质上处理的其实也是类，但是是一帮非常棘手、繁杂的类，这些类中不仅能划分出门派，还能划分出等级，同时存在着千变万化的扩展可能性——这使得我们必须对共性作更特别的处理、使用抽象类去降低扩展的成本，同时需要对类的性质作划分，于是有了这样的四个关键角色：

  • 抽象工厂（抽象类，它不能被用于生成具体实例）： 用于声明最终目标产品的共性。在一个系统里，抽象工厂可以有多个（大家可以想象我们的手机厂后来被一个更大的厂收购了，这个厂里除了手机抽象类，还有平板、游戏机抽象类等等），每一个抽象工厂对应的这一类的产品，被称为“产品族”。
  • 具体工厂（用于生成产品族里的一个具体的产品）： 继承自抽象工厂、实现了抽象工厂里声明的那些方法，用于创建具体的产品的类。
  • 抽象产品（抽象类，它不能被用于生成具体实例）： 上面我们看到，具体工厂里实现的接口，会依赖一些类，这些类对应到各种各样的具体的细粒度产品（比如操作系统、硬件等），这些具体产品类的共性各自抽离，便对应到了各自的抽象产品类。
  • 具体产品（用于生成产品族里的一个具体的产品所依赖的更细粒度的产品）： 比如我们上文中具体的一种操作系统、或具体的一种硬件等。

抽象工厂模式的定义，是围绕一个超级工厂创建其他工厂。本节内容对一些工作年限不多的同学来说可能不太友好，但抽象工厂目前来说在JS世界里也应用得并不广泛，所以大家不必拘泥于细节，只需留意以下三点：

  1. 学会用 ES6 模拟 JAVA 中的抽象类；
  2. 了解抽象工厂模式中四个角色的定位与作用；
  3. 对“开放封闭原则”形成自己的理解，知道它好在哪，知道执行它的必要性。