创建型-工厂模式

目录

场景假设

代码示例说明

简单工厂模式

工厂方法模式

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

抽象工厂

总结

---

场景假设

我们根据配置文件的后缀（json、xml、yaml、properties），选择不同的解析器（JsonRuleConfigParser、XmlRuleConfigParser、YamlRuleConfigParser、PropertiesRuleConfigParser ），将存储在文件中的配置解析成内存对象 RuleConfig。

说明：实例代码中的 IRuleConfigParser 是解析器接口（interface），JsonRuleConfigParser、XmlRuleConfigParser、YamlRuleConfigParser、PropertiesRuleConfigParser 是解析器接口的实现类

 

代码示例说明

代码仅供说明使用，不考虑健壮性

简单工厂模式

实现方式1：每次都创建新的对象

public class RuleConfigSource {     // 加载配置     public RuleConfig load(String ruleConfigFilePath) {         // 配置文件路径         String configPath = "/Users/liangpeng/sky.json";         // 读取配置         String configText = readConfig(configPath);         // 配置格式         String configFormat = "json";         // 根据配置格式获取配置解析器         IRuleConfigParser parser = RuleConfigParserFactory.createParser(configFormat);         // 将配置信息解析为 RuleConfig 对象         RuleConfig ruleConfig = parser.parse(configText);         return ruleConfig;     } }   // 每次创建新对象 public class RuleConfigParserFactory {     public static IRuleConfigParser createParser(String configFormat) {         IRuleConfigParser parser = null;         if ("json".equalsIgnoreCase(configFormat)) {             parser = new JsonRuleConfigParser();         } else if ("xml".equalsIgnoreCase(configFormat)) {             parser = new XmlRuleConfigParser();         } else if ("yaml".equalsIgnoreCase(configFormat)) {             parser = new YamlRuleConfigParser();         } else if ("properties".equalsIgnoreCase(configFormat)) {             parser = new PropertiesRuleConfigParser();         }         return parser;     } }

实现方式2：如果工厂创建出的对象可以复用，可以将对象缓存起来，每次从缓存中取出对象直接使用

public class RuleConfigParserFactory {     private static final Map<String, RuleConfigParser> cachedParsers = new HashMap<>();       static {         cachedParsers.put("json", new JsonRuleConfigParser());         cachedParsers.put("xml", new XmlRuleConfigParser());         cachedParsers.put("yaml", new YamlRuleConfigParser());         cachedParsers.put("properties", new PropertiesRuleConfigParser());     }       public static IRuleConfigParser createParser(String configFormat) {         if (configFormat == null || configFormat.isEmpty()) {             return null;// 返回null还是IllegalArgumentException全凭你自己说了算         }         IRuleConfigParser parser = cachedParsers.get(configFormat.toLowerCase());         return parser;     } }

尽管“简单工厂模式”的代码实现方式1中，有多处 if 分支判断逻辑，违背开闭原则，但权衡扩展性和可读性，这样的代码实现在大多数情况下（比如，不需要频繁地添加 parser，也没有太多的 parser）是没有问题的。

工厂方法模式

如果我们非得要将 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 类即可。所以，工厂方法模式比起简单工厂模式更加符合开闭原则。

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

public class RuleConfigSource {     public RuleConfig load(String ruleConfigFilePath) {         // 配置文件路径         String configPath = "/Users/liangpeng/sky.json";         // 读取配置         String configText = readConfig(configPath);         // 配置格式         String configFormat = "json";         // 根据配置格式获取解释器工厂类         IRuleConfigParserFactory parserFactory = createParserFactory(configFormat);         // 创建解析器         IRuleConfigParser parser = parserFactory.createParser();         RuleConfig ruleConfig = parser.parse(configText);         return ruleConfig;     }       // 根据配置格式获取解释器工厂类     private IRuleConfigParserFactory createParserFactory(configFormat) {         IRuleConfigParserFactory parserFactory = null;         if ("json".equalsIgnoreCase(configFormat)) {             parserFactory = new JsonRuleConfigParserFactory();         } else if ("xml".equalsIgnoreCase(configFormat)) {             parserFactory = new XmlRuleConfigParserFactory();         } else if ("yaml".equalsIgnoreCase(configFormat)) {             parserFactory = new YamlRuleConfigParserFactory();         } else if ("properties".equalsIgnoreCase(configFormat)) {             parserFactory = new PropertiesRuleConfigParserFactory();         }     } }

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

我们可以为工厂类再创建一个简单工厂，也就是工厂的工厂，用来创建工厂类对象或者说用来管理工厂类对象。代码如下，其中 RuleConfigParserFactoryMap 类是创建工厂对象的工厂类，getParserFactory() 返回的是缓存好的单例工厂对象。

public class RuleConfigSource {     public RuleConfig load(String ruleConfigFilePath) {         // 配置文件路径         String configPath = "/Users/liangpeng/sky.json";         // 读取配置         String configText = readConfig(configPath);         // 配置格式         String configFormat = "json";         // 根据配置格式获取配置解析工厂         IRuleConfigParserFactory parserFactory = RuleConfigParserFactoryMap.getParserFactory(configFormat);         // 获取配置解析器         IRuleConfigParser parser = parserFactory.createParser();         // 解析配置         RuleConfig ruleConfig = parser.parse(configText);         return ruleConfig;     } }   //因为工厂类只包含方法，不包含成员变量，完全可以复用， // 不需要每次都创建新的工厂类对象，所以，简单工厂模式的第二种实现思路更加合适。 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;     } }

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

    将复杂代码剥离出来，独立为函数或者类。剥离之后能让代码更加清晰，更加可读、可维护。但是，如果代码块本身并不复杂，就几行代码而已，我们完全没必要将它拆分成单独的函数或者类。

    基于这个设计思想，当对象的创建逻辑比较复杂，不只是简单的 new 一下就可以，而是要组合其他类对象，做各种初始化操作的时候，我们推荐使用工厂方法模式，将复杂的创建逻辑拆分到多个工厂类中，让每个工厂类都不至于过于复杂。而使用简单工厂模式，将所有的创建逻辑都放到一个工厂类中，会导致这个工厂类变得很复杂。

    除此之外，在某些场景下，如果对象不可复用，那工厂类每次都要返回不同的对象。如果我们使用简单工厂模式来实现，就只能选择“简单工厂模式”第一种包含 if 分支逻辑的实现方式。如果我们还想避免烦人的 if-else 分支逻辑，这个时候，我们就推荐使用工厂方法模式。

 

抽象工厂

定义：抽个毛线抽

总结

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

• 第一种情况：类似规则配置解析的例子，代码中存在 if-else 分支判断，动态地根据不同的类型创建不同的对象。针对这种情况，我们就考虑使用工厂模式，将这一大坨 if-else 创建对象的代码抽离出来，放到工厂类中。
• 还有一种情况，尽管我们不需要根据不同的类型创建不同的对象，但是，单个对象本身的创建过程比较复杂，比如前面提到的要组合其他类对象，做各种初始化操作。在这种情况下，我们也可以考虑使用工厂模式，将对象的创建过程封装到工厂类中

 

     对于第一种情况，当每个对象的创建逻辑都比较简单的时候，我推荐使用简单工厂模式，将多个对象的创建逻辑放到一个工厂类中。

当每个对象的创建逻辑都比较复杂的时候，为了避免设计一个过于庞大的简单工厂类，我推荐使用工厂方法模式，将创建逻辑拆分得更

细，每个对象的创建逻辑独立到各自的工厂类中。同理，对于第二种情况，因为单个对象本身的创建逻辑就比较复杂，所以，我建议使

用工厂方法模式。

 

    除了刚刚提到的这几种情况之外，如果创建对象的逻辑并不复杂，那我们就直接通过 new 来创建对象就可以了，不需要使用工厂模式。

 

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

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

 

参考资料

极客时间--设计模式之美--第44讲，45讲