创建型：抽象工厂模式

目录介绍

• 01.模式简单介绍
• 02.模式结构介绍
• 03.抽象工厂模式
• 04.抽象工厂优缺点
• 05.如何选工厂模式
• 06.问题答疑思考

01.模式简单介绍

1.1 定义

• 抽象工厂模式(Abstract Factory Pattern)：提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。抽象工厂模式又称为Kit模式，属于对象创建型模式。
• 定义很难懂？没错，看起来是很抽象，不过这正反应了这种模式的强大。下面具体阐述下定义。

1.2 定义阐述

• 在工厂方法模式中具体工厂负责生产具体的产品，每一个具体工厂对应一种或几种具体产品，工厂方法也具有唯一性，一般情况下，一个具体工厂中只有一个工厂方法或者一组重载的工厂方法。但是有时候我们需要一个工厂可以提供多个不同种类产品对象，而不是单一种类的产品对象。

• 为了更清晰地理解工厂方法模式，需要先引入两个概念：

  • 产品等级结构：产品等级结构即产品的继承结构，如一个抽象类是电视机，其子类有海尔电视机、海信电视机、TCL电视机，则抽象电视机与具体品牌的电视机之间构成了一个产品等级结构，抽象电视机是父类，而具体品牌的电视机是其子类。
  • 产品族： 在抽象工厂模式中，产品族是指由同一个工厂生产的，位于不同产品等级结构中的一组产品，如海尔电器工厂生产的海尔电视机、海尔电冰箱，海尔电视机位于电视机产品等级结构中，海尔电冰箱位于电冰箱产品等级结构中。

• 当系统所提供的工厂所需生产的具体产品并不是一个简单的对象，而是多个位于不同产品等级结构中属于不同类型的具体产品时需要使用抽象工厂模式。

  • 抽象工厂模式是所有形式的工厂模式中最为抽象和最具一般性的一种形态。
  • 抽象工厂模式与工厂方法模式最大的区别在于，工厂方法模式针对的是一个产品等级结构，而抽象工厂模式则需要面对多个产品等级结构，一个工厂等级结构可以负责多个不同产品等级结构中的产品对象的创建 。当一个工厂等级结构可以创建出分属于不同产品等级结构的一个产品族中的所有对象时，抽象工厂模式比工厂方法模式更为简单、有效率。

02.模式结构介绍

2.1 模式结构

• 如下所示

  • 

• 抽象工厂模式包含如下角色：

  • AbstractFactory：抽象工厂
  • ConcreteFactory：具体工厂
  • AbstractProduct：抽象产品
  • Product：具体产品

2.2 时序图

• 如下所示

  • 

• 如何理解

  • ①先调用具体工厂对象中的方法createProductX()。根据具体工厂不同可以选择不同的方法，针对同一种工厂也可以选择不同的方法创建不同类型的产品对象。
  • ②根据传入产品类型参数（也可以无参），获得具体的产品对象
  • ③返回产品对象并使用

03.抽象工厂模式

• 讲完了简单工厂、工厂方法，我们再来看抽象工厂模式。抽象工厂模式的应用场景比较特殊，没有前两种常用，你简单了解一下就可以了。

• 在简单工厂和工厂方法中，类只有一种分类方式。比如，在规则配置解析那个例子中，解析器类只会根据配置文件格式（Json、Xml、Yaml……）来分类。但是，如果类有两种分类方式，比如，我们既可以按照配置文件格式来分类，也可以按照解析的对象（Rule 规则配置还是 System 系统配置）来分类，那就会对应下面这 8 个 parser 类。

  针对规则配置的解析器：基于接口IRuleConfigParser
  JsonRuleConfigParser
  XmlRuleConfigParser
  YamlRuleConfigParser
  PropertiesRuleConfigParser
  
  针对系统配置的解析器：基于接口ISystemConfigParser
  JsonSystemConfigParser
  XmlSystemConfigParser
  YamlSystemConfigParser
  PropertiesSystemConfigParser

• 针对这种特殊的场景，如果还是继续用工厂方法来实现的话，我们要针对每个 parser 都编写一个工厂类，也就是要编写 8 个工厂类。如果我们未来还需要增加针对业务配置的解析器（比如 IBizConfigParser），那就要再对应地增加 4 个工厂类。而我们知道，过多的类也会让系统难维护。这个问题该怎么解决呢？

• 抽象工厂就是针对这种非常特殊的场景而诞生的。我们可以让一个工厂负责创建多个不同类型的对象（IRuleConfigParser、ISystemConfigParser 等），而不是只创建一种 parser 对象。这样就可以有效地减少工厂类的个数。具体的代码实现如下所示：

  public interface IConfigParserFactory {
    IRuleConfigParser createRuleParser();
    ISystemConfigParser createSystemParser();
    //此处可以扩展新的parser类型，比如IBizConfigParser
  }
  
  public class JsonConfigParserFactory implements IConfigParserFactory {
    @Override
    public IRuleConfigParser createRuleParser() {
      return new JsonRuleConfigParser();
    }
  
    @Override
    public ISystemConfigParser createSystemParser() {
      return new JsonSystemConfigParser();
    }
  }
  
  public class XmlConfigParserFactory implements IConfigParserFactory {
    @Override
    public IRuleConfigParser createRuleParser() {
      return new XmlRuleConfigParser();
    }
  
    @Override
    public ISystemConfigParser createSystemParser() {
      return new XmlSystemConfigParser();
    }
  }
  
  // 省略YamlConfigParserFactory和PropertiesConfigParserFactory代码

04.抽象工厂优缺点

• 优点

  • ①抽象工厂模式隔离了具体类的生成，使得客户并不需要知道什么被创建。由于这种隔离，更换一个具体工厂就变得相对容易。所有的具体工厂都实现了抽象工厂中定义的那些公共接口，因此只需改变具体工厂的实例，就可以在某种程度上改变整个软件系统的行为。另外，应用抽象工厂模式可以实现高内聚低耦合的设计目的，因此抽象工厂模式得到了广泛的应用。
  • ②增加新的具体工厂和产品族很方便，因为一个具体的工厂实现代表的是一个产品族，无须修改已有系统，符合“开闭原则”。

• 缺点

  • 在添加新的产品对象（不同于现有的产品等级结构）时，难以扩展抽象工厂来生产新种类的产品，这是因为在抽象工厂角色中规定了所有可能被创建的产品集合，要支持新种类的产品就意味着要对该接口进行扩展，而这将涉及到对抽象工厂角色及其所有子类的修改，显然会带来较大的不便。
  • 开闭原则的倾斜性（增加新的工厂和产品族容易，增加新的产品等级结构麻烦）。

• 适用环境

  • ①一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节，这对于所有类型的工厂模式都是重要的。
  • ②系统中有多于一个的产品族，而每次只使用其中某一产品族。与工厂方法模式的区别
  • ③属于同一个产品族的产品将在一起使用，这一约束必须在系统的设计中体现出来。
  • ④系统提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于具体实现。

05.如何选工厂模式

• 当创建逻辑比较复杂，是一个“大工程”的时候，我们就考虑使用工厂模式，封装对象的创建过程，将对象的创建和使用相分离。何为创建逻辑比较复杂呢？我总结了下面两种情况。

  • 第一种情况：类似规则配置解析的例子，代码中存在 if-else 分支判断，动态地根据不同的类型创建不同的对象。针对这种情况，我们就考虑使用工厂模式，将这一大坨 if-else 创建对象的代码抽离出来，放到工厂类中。
  • 还有一种情况，尽管我们不需要根据不同的类型创建不同的对象，但是，单个对象本身的创建过程比较复杂，比如前面提到的要组合其他类对象，做各种初始化操作。在这种情况下，我们也可以考虑使用工厂模式，将对象的创建过程封装到工厂类中。
• 对于第一种情况，当每个对象的创建逻辑都比较简单的时候，我推荐使用简单工厂模式，将多个对象的创建逻辑放到一个工厂类中。当每个对象的创建逻辑都比较复杂的时候，为了避免设计一个过于庞大的简单工厂类，我推荐使用工厂方法模式，将创建逻辑拆分得更细，每个对象的创建逻辑独立到各自的工厂类中。同理，对于第二种情况，因为单个对象本身的创建逻辑就比较复杂，所以，我建议使用工厂方法模式。
• 除了刚刚提到的这几种情况之外，如果创建对象的逻辑并不复杂，那我们就直接通过 new 来创建对象就可以了，不需要使用工厂模式。

• 现在，我们上升一个思维层面来看工厂模式，它的作用无外乎下面这四个。这也是判断要不要使用工厂模式的最本质的参考标准。

  • 封装变化：创建逻辑有可能变化，封装成工厂类之后，创建逻辑的变更对调用者透明。
  • 代码复用：创建代码抽离到独立的工厂类之后可以复用。
  • 隔离复杂性：封装复杂的创建逻辑，调用者无需了解如何创建对象。
  • 控制复杂度：将创建代码抽离出来，让原本的函数或类职责更单一，代码更简洁。

06.问题答疑思考

• 工厂模式是一种非常常用的设计模式，在很多开源项目、工具类中到处可见，比如 Java 中的 Calendar、DateFormat 类。除此之外，你还知道哪些用工厂模式实现类？可以留言说一说它们为什么要设计成工厂模式类？
• 实际上，简单工厂模式还叫作静态工厂方法模式（Static Factory Method Pattern）。之所以叫静态工厂方法模式，是因为其中创建对象的方法是静态的。那为什么要设置成静态的呢？设置成静态的，在使用的时候，是否会影响到代码的可测试性呢？

更多内容

• GitHub：https://github.com/yangchong211
• 博客：https://juejin.cn/user/1978776659695784
• 开源博客汇总：https://github.com/yangchong211/YCBlogs