创建型：工厂方法模式

目录介绍

• 01.为何有工厂方法
• 02.工厂方法模式结构
• 03.工厂方法演变
• 04.演变带来的问题
• 05.工厂方法优化
• 06.如何选择合适的
• 07.工厂方法优缺点
• 08.适用场景说明

01.为何有工厂方法

• 对该系统进行修改，不再设计一个按钮工厂类来统一负责所有产品的创建，而是将具体按钮的创建过程交给专门的工厂子类去完成。
• 先定义一个抽象的按钮工厂类，再定义具体的工厂类来生成圆形按钮、矩形按钮、菱形按钮等，它们实现在抽象按钮工厂类中定义的方法。
• 这种抽象化的结果使这种结构可以在不修改具体工厂类的情况下引进新的产品，如果出现新的按钮类型，只需要为这种新类型的按钮创建一个具体的工厂类就可以获得该新按钮的实例，这一特点无疑使得工厂方法模式具有超越简单工厂模式的优越性，更加符合“开闭原则”。

02.工厂方法模式结构

• ●Product：抽象产品

  • 工厂方法模式所创建的对象的超类，也就是所有产品类的共同父类或共同拥有的接口。在实际的系统中，这个角色也常常使用抽象类实现。

• ●ConcreteProduct：具体产品

  • 这个角色实现了抽象产品（Product）所声明的接口，工厂方法模式所创建的每一个对象都是某个具体产品的实例。

• ●Factory：抽象工厂

  • 担任这个角色的是工厂方法模式的核心，任何在模式中创建对象的工厂类必须实现这个接口。在实际的系统中，这个角色也常常使用抽象类实现。

• ●ConcreteFactory：具体工厂

  • 担任这个角色的是实现了抽象工厂接口的具体Java类。具体工厂角色含有与业务密切相关的逻辑，并且受到使用者的调用以创建具体产品对象。

03.工厂方法演变

• 如果我们非得要将 if 分支逻辑去掉，那该怎么办呢？

  • 比较经典处理方法就是利用多态。按照多态的实现思路，对上面的代码进行重构。重构之后的代码如下所示：

  public interface IRuleConfigParserFactory {
    IRuleConfigParser createParser();
  }
  
  public class JsonRuleConfigParserFactory implements IRuleConfigParserFactory {
    @Override
    public IRuleConfigParser createParser() {
      return new JsonRuleConfigParser();
    }
  }
  
  public class XmlRuleConfigParserFactory implements IRuleConfigParserFactory {
    @Override
    public IRuleConfigParser createParser() {
      return new XmlRuleConfigParser();
    }
  }
  
  public class YamlRuleConfigParserFactory implements IRuleConfigParserFactory {
    @Override
    public IRuleConfigParser createParser() {
      return new YamlRuleConfigParser();
    }
  }
  
  public class PropertiesRuleConfigParserFactory implements IRuleConfigParserFactory {
    @Override
    public IRuleConfigParser createParser() {
      return new PropertiesRuleConfigParser();
    }
  }

• 实际上，这就是工厂方法模式的典型代码实现。

  • 这样当我们新增一种 parser 的时候，只需要新增一个实现了 IRuleConfigParserFactory 接口的 Factory 类即可。
  • 所以，工厂方法模式比起简单工厂模式更加符合开闭原则。

04.演变带来的问题

• 从上面的工厂方法的实现来看，一切都很完美，但是实际上存在挺大的问题。问题存在于这些工厂类的使用上。接下来，我们看一下，如何用这些工厂类来实现 RuleConfigSource 的 load() 函数。具体的代码如下所示：

  public class RuleConfigSource {
    public RuleConfig load(String ruleConfigFilePath) {
      String ruleConfigFileExtension = getFileExtension(ruleConfigFilePath);
  
      IRuleConfigParserFactory parserFactory = null;
      if ("json".equalsIgnoreCase(ruleConfigFileExtension)) {
        parserFactory = new JsonRuleConfigParserFactory();
      } else if ("xml".equalsIgnoreCase(ruleConfigFileExtension)) {
        parserFactory = new XmlRuleConfigParserFactory();
      } else if ("yaml".equalsIgnoreCase(ruleConfigFileExtension)) {
        parserFactory = new YamlRuleConfigParserFactory();
      } else if ("properties".equalsIgnoreCase(ruleConfigFileExtension)) {
        parserFactory = new PropertiesRuleConfigParserFactory();
      } else {
        throw new InvalidRuleConfigException("Rule config file format is not supported: " + ruleConfigFilePath);
      }
      IRuleConfigParser parser = parserFactory.createParser();
  
      String configText = "";
      //从ruleConfigFilePath文件中读取配置文本到configText中
      RuleConfig ruleConfig = parser.parse(configText);
      return ruleConfig;
    }
  
    private String getFileExtension(String filePath) {
      //...解析文件名获取扩展名，比如rule.json，返回json
      return "json";
    }
  }

• 从上面的代码实现来看，工厂类对象的创建逻辑又耦合进了 load() 函数中，跟我们最初的代码版本非常相似，引入工厂方法非但没有解决问题，反倒让设计变得更加复杂了。那怎么来解决这个问题呢？

05.工厂方法优化

• 我们可以为工厂类再创建一个简单工厂，也就是工厂的工厂，用来创建工厂类对象。这段话听起来有点绕，我把代码实现出来了，你一看就能明白了。其中，RuleConfigParserFactoryMap 类是创建工厂对象的工厂类，getParserFactory() 返回的是缓存好的单例工厂对象。

  public class RuleConfigSource {
    public RuleConfig load(String ruleConfigFilePath) {
      String ruleConfigFileExtension = getFileExtension(ruleConfigFilePath);
  
      IRuleConfigParserFactory parserFactory = RuleConfigParserFactoryMap.getParserFactory(ruleConfigFileExtension);
      if (parserFactory == null) {
        throw new InvalidRuleConfigException("Rule config file format is not supported: " + ruleConfigFilePath);
      }
      IRuleConfigParser parser = parserFactory.createParser();
  
      String configText = "";
      //从ruleConfigFilePath文件中读取配置文本到configText中
      RuleConfig ruleConfig = parser.parse(configText);
      return ruleConfig;
    }
  
    private String getFileExtension(String filePath) {
      //...解析文件名获取扩展名，比如rule.json，返回json
      return "json";
    }
  }
  
  //因为工厂类只包含方法，不包含成员变量，完全可以复用，
  //不需要每次都创建新的工厂类对象，所以，简单工厂模式的第二种实现思路更加合适。
  public class RuleConfigParserFactoryMap { //工厂的工厂
    private static final Map<String, IRuleConfigParserFactory> cachedFactories = new HashMap<>();
  
    static {
      cachedFactories.put("json", new JsonRuleConfigParserFactory());
      cachedFactories.put("xml", new XmlRuleConfigParserFactory());
      cachedFactories.put("yaml", new YamlRuleConfigParserFactory());
      cachedFactories.put("properties", new PropertiesRuleConfigParserFactory());
    }
  
    public static IRuleConfigParserFactory getParserFactory(String type) {
      if (type == null || type.isEmpty()) {
        return null;
      }
      IRuleConfigParserFactory parserFactory = cachedFactories.get(type.toLowerCase());
      return parserFactory;
    }
  }

• 当我们需要添加新的规则配置解析器的时候，我们只需要创建新的 parser 类和 parser factory 类，并且在 RuleConfigParserFactoryMap 类中，将新的 parser factory 对象添加到 cachedFactories 中即可。代码的改动非常少，基本上符合开闭原则。
• 实际上，对于规则配置文件解析这个应用场景来说，工厂模式需要额外创建诸多 Factory 类，也会增加代码的复杂性，而且，每个 Factory 类只是做简单的 new 操作，功能非常单薄（只有一行代码），也没必要设计成独立的类，所以，在这个应用场景下，简单工厂模式简单好用，比工厂方法模式更加合适。

06.如何选择合适的

• 那什么时候该用工厂方法模式，而非简单工厂模式呢？

  • 前面提到，之所以将某个代码块剥离出来，独立为函数或者类，原因是这个代码块的逻辑过于复杂，剥离之后能让代码更加清晰，更加可读、可维护。但是，如果代码块本身并不复杂，就几行代码而已，我们完全没必要将它拆分成单独的函数或者类。
• 基于这个设计思想，当对象的创建逻辑比较复杂，不只是简单的 new 一下就可以，而是要组合其他类对象，做各种初始化操作的时候，我们推荐使用工厂方法模式，将复杂的创建逻辑拆分到多个工厂类中，让每个工厂类都不至于过于复杂。而使用简单工厂模式，将所有的创建逻辑都放到一个工厂类中，会导致这个工厂类变得很复杂。
• 除此之外，在某些场景下，如果对象不可复用，那工厂类每次都要返回不同的对象。如果我们使用简单工厂模式来实现，就只能选择第一种包含 if 分支逻辑的实现方式。如果我们还想避免烦人的 if-else 分支逻辑，这个时候，我们就推荐使用工厂方法模式。

07.工厂方法优缺点

• 优点

  • ①在工厂方法模式中，工厂方法用来创建客户所需要的产品，同时还向客户隐藏了哪种具体产品类将被实例化这一细节，用户只需要关心所需产品对应的工厂，无须关心创建细节，甚至无须知道具体产品类的类名。
  • ②基于工厂角色和产品角色的多态性设计是工厂方法模式的关键。它能够使工厂可以自主确定创建何种产品对象，而如何创建这个对象的细节则完全封装在具体工厂内部。工厂方法模式之所以又被称为多态工厂模式，是因为所有的具体工厂类都具有同一抽象父类。
  • ③使用工厂方法模式的另一个优点是在系统中加入新产品时，无须修改抽象工厂和抽象产品提供的接口，无须修改客户端，也无须修改其他的具体工厂和具体产品，而只要添加一个具体工厂和具体产品就可以了。这样，系统的可扩展性也就变得非常好，完全符合“开闭原则”，这点比简单工厂模式更优秀。

• 缺点

  • ①在添加新产品时，需要编写新的具体产品类，而且还要提供与之对应的具体工厂类，系统中类的个数将成对增加，在一定程度上增加了系统的复杂度，有更多的类需要编译和运行，会给系统带来一些额外的开销。
  • ②由于考虑到系统的可扩展性，需要引入抽象层，在客户端代码中均使用抽象层进行定义，增加了系统的抽象性和理解难度，且在实现时可能需要用到DOM、反射等技术，增加了系统的实现难度。

08.适用场景说明

• ①一个类不知道它所需要的对象的类：

  • 在工厂方法模式中，客户端不需要知道具体产品类的类名，只需要知道所对应的工厂即可，具体的产品对象由具体工厂类创建；客户端需要知道创建具体产品的工厂类。

• ②一个类通过其子类来指定创建哪个对象：

  • 在工厂方法模式中，对于抽象工厂类只需要提供一个创建产品的接口，而由其子类来确定具体要创建的对象，利用面向对象的多态性和里氏代换原则，在程序运行时，子类对象将覆盖父类对象，从而使得系统更容易扩展。

• ③将创建对象的任务委托给多个工厂子类中的某一个

  • 客户端在使用时可以无须关心是哪一个工厂子类创建产品子类，需要时再动态指定，可将具体工厂类的类名存储在配置文件或数据库中。