1. 工厂模式的分类
所有的工厂方法都是用来封装对象的创建。
- 一般情况下，工厂模式分为三种更加细分的类型：简单工厂、工厂方法和抽象工厂。
- 在 GoF 的《设计模式》一书中，它将简单工厂模式看作是工厂方法模式的一种特例，所以工厂模式只被分成了工厂方法和抽象工厂两类。
- 实际上，前面一种分类方法更加常见。
在这三种细分的工厂模式中：
- 简单工厂、工厂方法原理比较简单，在实际的项目中也比较常用。
- 而抽象工厂的原理稍微复杂点，在实际的项目中相对也不常用。
以一个配置解析类为例，简单的对象创建实现方式如下：
/** * 资源解析器 * * 根据配置文件的后缀（json、xml、yaml、properties）， * 选择不同的解析器（JsonRuleConfigParser、XmlRuleConfigParser……）， * 将存储在文件中的配置解析成内存对象 RuleConfig */public class RuleConfigSource { public RuleConfig load(String ruleConfigFilePath) throws InvalidRuleConfigException { String ruleConfigFileExt = getFileExtension(ruleConfigFilePath); IRuleConfigParser parser = null; if ("json".equalsIgnoreCase(ruleConfigFileExt)) { parser = new JsonRuleConfigParser(); } else if ("xml".equalsIgnoreCase(ruleConfigFileExt)) { parser = new XmlRuleConfigParser(); } else if ("yaml".equalsIgnoreCase(ruleConfigFileExt)) { parser = new YamlRuleConfigParser(); } else if ("properties".equalsIgnoreCase(ruleConfigFileExt)) { parser = new PropertiesRuleConfigParser(); } else { throw new InvalidRuleConfigException( "Rule config file format is not supported: " + ruleConfigFilePath); } String configText = ""; //从ruleConfigFilePath文件中读取配置文本到configText中 RuleConfig ruleConfig = parser.parse(configText); return ruleConfig; }
private String getFileExtension(String ruleConfigFilePath) {
//...解析文件名获取扩展名，比如rule.json，返回json String ext = "json"; return ext; }}2. 简单工厂模式
大部分工厂类都是以“Factory”这个单词结尾的，但也不是必须的，比如 Java 中的 DateFormat、Calender。
2.1 简单工厂实现方法
2.1.1 if分支
- 将代码中if-else逻辑判断创建对象的部分逻辑剥离出来，抽象成 createXX() 函数
- 将 createXX() 函数剥离到一个独立的类中，让这个类只负责对象的创建，这个类就是简单工厂方法的第一种实现。
/** * 简单工厂模式类 * * 将代码中涉及解析器 parser 创建的部分逻辑剥离出来，抽象成 createParser() 函数 * 将 createParser() 函数剥离到一个独立的类中，让这个类只负责对象的创建。 * 这个类就是简单工厂模式类 */public class RuleConfigParserFactory1 { public static IRuleConfigParser createParser(String ruleConfigFileExt) { IRuleConfigParser parser = null; if ("json".equalsIgnoreCase(ruleConfigFileExt)) { parser = new JsonRuleConfigParser(); } else if ("xml".equalsIgnoreCase(ruleConfigFileExt)) { parser = new XmlRuleConfigParser(); } else if ("yaml".equalsIgnoreCase(ruleConfigFileExt)) { parser = new YamlRuleConfigParser(); } else if ("properties".equalsIgnoreCase(ruleConfigFileExt)) { parser = new PropertiesRuleConfigParser(); } return parser; }}
/** * 资源解析器 * * 根据配置文件的后缀（json、xml、yaml、properties）， * 选择不同的解析器（JsonRuleConfigParser、XmlRuleConfigParser……）， * 将存储在文件中的配置解析成内存对象 RuleConfig */public class RuleConfigSource { public RuleConfig load(String ruleConfigFilePath) throws InvalidRuleConfigException { String ruleConfigFileExt = getFileExtension(ruleConfigFilePath); IRuleConfigParser parser = RuleConfigParserFactory1.createParser(ruleConfigFileExt); if (null == parser) { throw new InvalidRuleConfigException( "Rule config file format is not supported: " + ruleConfigFilePath); } String configText = ""; //从ruleConfigFilePath文件中读取配置文本到configText中 RuleConfig ruleConfig = parser.parse(configText); return ruleConfig; }
private String getFileExtension(String ruleConfigFilePath) {
//...解析文件名获取扩展名，比如rule.json，返回json String ext = "json"; return ext; }}2.1.2 Map方式
将if判断逻辑用Map方式的单例代替。
/** * 第二种简单工厂模式实现方法 */public class RuleConfigParserFactory2 { private static Map<String, IRuleConfigParser> cacheParsers = new HashMap<>();
static { cacheParsers.put("json", new JsonRuleConfigParser()); cacheParsers.put("xml", new XmlRuleConfigParser()); cacheParsers.put("yaml", new YamlRuleConfigParser()); cacheParsers.put("properties", new PropertiesRuleConfigParser()); }
public static IRuleConfigParser createParser(String ruleConfigFileExt) { if (StringUtils.isBlank(ruleConfigFileExt)) { return null; } IRuleConfigParser parser = cacheParsers.get(ruleConfigFileExt); return parser; }
}
// RuleConfigSource中的用法和方法一中的相似，这里故省略public class RuleConfigSource { // ...}2.2 简单工厂使用范围
当每个对象创建比较简单，功能单薄时，没必要设计成独立的类，完全可以将所有的放在一个工厂类中时，简单工厂模式简单好用。
如对于规则配置文件解析这个应用场景来说，工厂模式需要额外创建诸多 Factory 类，也会增加代码的复杂性，而且，每个 Factory 类只是做简单的 new 操作，功能非常单薄（只有一行代码），也没必要设计成独立的类，所以，在这个应用场景下，简单工厂模式简单好用，比工厂方法模式更加合适。
2.3 存在if分支判断逻辑和违背开闭原则是否可取
简单工厂模式的代码实现中，有多处 if 分支判断逻辑，违背开闭原则，但权衡扩展性和可读性，这样的代码实现在大多数情况下（比如，不需要频繁地添加 parser，也没有太多的 parser）是没有问题的。
2.3.1 关于多个if分支判断逻辑
关于第一种实现中if分支逻辑，若if分支不多，也是可以接受的。
若应用多态或设计模式来替代 if 分支判断逻辑， 虽然提高了代码的扩展性，更加符合开闭原则，但也增加了类的个数，牺牲了代码的可读性。
2.3.2 关于违背开闭原则：
如果我们要添加新的 parser，那势必要改动到 RuleConfigParserFactory 的代码，此时属于违反开闭原则。
若不是需要频繁地添加新的 parser，只是偶尔修改一下 RuleConfigParserFactory 代码，也是可以接受的。
2.4 静态工厂方法模式（Static Factory Method Pattern）
简单工厂方法的实现，static关键字不是必须的（不使用时需要手动创建简单工厂对象），但利用静态方法定义一个简单的工厂是一种很常见的技巧，此时的简单工厂模式也叫作静态工厂方法模式(Static Factory Method Pattern)。
静态工厂方法模式不需要使用创建对象的方法来实例化对象，但也导致了其不能通过继承来改变创建方法的行为、
3. 工厂模式
利用多态替换简单工厂中的if分支逻辑是一种经典的工厂方法的实现。
工厂模式定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个（即该创建的对象是什么）。
工厂模式让类把实例化推迟到了子类。
3.1 实现方式
3.1.1 经典实现
先创建抽象创造者类（如IRuleConfigParserFactory），其定义了抽象的工厂方法（如createParser()），让子类(即具体创造者，如JsonRuleConfigParserFactory)实现此方法制造产品(如JsonRuleConfigParser)。
/** * 抽象创造者类 */public interface IRuleConfigParserFactory { IRuleConfigParser createParser();}/** * 具体创造者类-用于处理json文件解析对象的创建 */public class JsonRuleConfigParserFactory implements IRuleConfigParserFactory { @Override public IRuleConfigParser createParser() { return new JsonRuleConfigParser(); }}
// ... 其余类型的解析方式类似，故省略
/*** 资源解析器*/public class RuleConfigSource { public RuleConfig load(String ruleConfigFilePath) throws InvalidRuleConfigException { String ruleConfigFileExt = getFileExtension(ruleConfigFilePath); IRuleConfigParserFactory parserFactory = null;
if ("json".equalsIgnoreCase(ruleConfigFileExt)) { parserFactory = new JsonRuleConfigParserFactory(); } else if ("xml".equalsIgnoreCase(ruleConfigFileExt)) { parserFactory = new XmlRuleConfigParserFactory(); } else if ("yaml".equalsIgnoreCase(ruleConfigFileExt)) { parserFactory = new YamlRuleConfigParserFactory(); } else if ("properties".equalsIgnoreCase(ruleConfigFileExt)) { 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; }
// ...}优势：
当我们新增一种 parser 的时候，只需要新增一个实现了 IRuleConfigParserFactory 接口的 Factory 类即可。工厂方法模式比起简单工厂模式更加符合开闭原则。
不足：
工厂类对象的创建逻辑又耦合进了 load() 函数中，跟我们最初的代码版本非常相似，引入工厂方法非但没有解决问题，反倒让设计变得更加复杂了。
3.1.2 单例+简单工厂+工厂模式
第一种方案不足之处的解决方案是可以为工厂类再创建一个简单工厂，也就是工厂的工厂，用来创建工厂类对象。
RuleConfigParserFactoryMap 类是创建工厂对象的工厂类，getParserFactory() 返回的是缓存好的单例工厂对象。
/** * 实现方法二 * * 因为工厂类只包含方法，不包含成员变量，完全可以复用， * 不需要每次都创建新的工厂类对象，所以，简单工厂模式的第二种实现思路更加合适。 */public class RuleConfigParserFactoryMap { private static final Map<String, IRuleConfigParserFactory> cacheFactorues = new HashMap<>();
static { cacheFactorues.put("json", new JsonRuleConfigParserFactory()); cacheFactorues.put("xml", new XmlRuleConfigParserFactory()); cacheFactorues.put("yaml", new YamlRuleConfigParserFactory()); cacheFactorues.put("properties", new PropertiesRuleConfigParserFactory()); }
public static IRuleConfigParserFactory getParserFactory (String type){ if (StringUtils.isBlank(type)) { return null; } IRuleConfigParserFactory parserFactory = cacheFactorues.get(type); return parserFactory; }
}
/*** 资源解析器*/public class RuleConfigSource { public RuleConfig load(String ruleConfigFilePath) throws InvalidRuleConfigException { String ruleConfigFileExt = getFileExtension(ruleConfigFilePath); IRuleConfigParser parser = null; IRuleConfigParserFactory parserFactory = RuleConfigParserFactoryMap.getParserFactory(ruleConfigFileExt); if (null == parserFactory) { throw new InvalidRuleConfigException( "Rule config file format is not supported: " + ruleConfigFilePath); } String configText = ""; //从ruleConfigFilePath文件中读取配置文本到configText中 RuleConfig ruleConfig = parser.parse(configText); return ruleConfig; } // ...}当我们需要添加新的规则配置解析器的时候，我们只需要创建新的 parser 类和 parser factory 类，并且在 RuleConfigParserFactoryMap 类中，将新的 parser factory 对象添加到 cachedFactories 中即可。代码的改动非常少，基本上符合开闭原则。
3.2 工厂模式适用范围
- 当对象的创建逻辑比较复杂，不只是简单的 new 一下就可以，而是要组合其他类对象，做各种初始化操作的时候，我们推荐使用工厂方法模式，将复杂的创建逻辑拆分到多个工厂类中，让每个工厂类都不至于过于复杂。而使用简单工厂模式，将所有的创建逻辑都放到一个工厂类中，会导致这个工厂类变得很复杂。
- 在某些场景下，如果对象不可复用，工厂类每次都要返回不同的对象。同时想避免烦人的 if-else 分支逻辑时推荐使用工厂方法模式。
4. 抽象工厂模式
抽象工厂模式提供了一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。
4.1 实现方式
抽象工厂模式让一个工厂负责创建多个不同类型的对象（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(); }}// ... 其余解析类的和Json的相似。// 在RuleConfigSource中的用法和工厂模式相似。4.2 工厂模式与抽象工厂模式
- 所有工厂模式都通过减少应用程序和具体类之间的依赖促进松耦合。
- 工厂模式使用继承：把对象的创建委托给子类，子类实现工厂方法来创建对象。
- 抽象工厂使用对象组合：对象的创建被实现在工厂接口所暴露出来的方法中。
- 工厂方法允许类将实例化延迟到子类进行。
- 抽象工厂创建相关的对象家族，而不需要依赖他们的具体类。
- 抽象工厂经常使用工厂方法来实现自己的具体工厂。
5. 工厂模式的作用
- 封装变化：创建逻辑有可能变化，封装成工厂类之后，创建逻辑的变更对调用者透明。
- 代码复用： 创建代码抽离到独立的工厂类之后可以复用。
- 隔离复杂性：封装复杂的创建逻辑，调用者无需了解如何创建对象。
- 控制复杂度：将创建代码抽离出来，让原本的函数或类职责更单一，代码更简洁。
6. DI容器
依赖倒置原则指导我们避免依赖的具体类型，而要尽量依赖抽象。
6.1 工厂模式与DI容器的区别
- DI 容器底层最基本的设计思路就是基于工厂模式的。DI 容器相当于一个大的工厂类，负责在程序启动的时候，根据配置（要创建哪些类对象，每个类对象的创建需要依赖哪些其他类对象）事先创建好对象。当应用程序需要使用某个类对象的时候，直接从容器中获取即可。正是因为它持有一堆对象，所以这个框架才被称为“容器”。
- DI容器处理的是更大的对象创建工程：工厂模式中，一个工厂类只负责某个类对象或者某一组相关类对象（继承自同一抽象类或者接口的子类）的创建，而 DI 容器负责的是整个应用中所有类对象的创建。
- DI 容器负责的事情要比单纯的工厂模式要多。比如，它还包括配置的解析、对象生命周期的管理。
6.2 DI 容器的核心功能
一个简单的 DI 容器的核心功能一般有三个：配置解析、对象创建和对象生命周期管理。
6.3 DI容器实现
一个简单的 DI 容器的实现原理，其核心逻辑主要包括：配置文件解析，以及根据配置文件通过“反射”语法来创建对象。
- 创建对象的过程就应用到了工厂模式。
- 对象创建、组装、管理完全有 DI 容器来负责，跟具体业务代码解耦，让程序员聚焦在业务代码的开发上。
7. 参考资料
- 设计模式之美
- 《Head First 设计模式》
评论