浅谈设计模式（1）：简单工厂模式

• 为什么需要简单工厂模式？
• 一个案例
• • 最简单的办法
  • 更好的办法
• 简单工厂模式与 new 的对比
• 代码示例

简单工厂模式是一种创建型设计模式，换句话说就是用来创建对象的。

创建对象很简单，用 new 关键字就可以了。为什么需要简单工厂模式呢？

如果需求永远不会变化，一遍写完就可以了，那么的确用 new 关键字来创建对象就足够了，没什么问题。

但实际情况往往比较复杂。

说一个根据实际项目改编的案例：例如，现在的需求是要按某种方式处理数据，我们可以新建一个 DataProcessor 类，然后用 DataProcessor dataProcessor = new DataProcessor() 来获取一个实例。

然而，后续需求不断在变化：

• 过了一阵子，处理数据的方式变了。假设之前是用 A 方式来处理数据，现在需要用另一种 B 方式来处理数据；
• 又过了一阵子，人们发现，其实原本的 A 方式也挺好啊！又要改回 A 方式；
• 又过了一阵子，人们发现，对于不同情况应该采用不同的数据处理方式。于是需要根据条件判断，决定是用 A 方式还是 B 方式来处理数据；
• 又过了一阵子，人们发现，实际情况很复杂，需要根据具体条件，采用 A、B、C、D、E 等方式来处理数据；

这时候，最简单的办法就是直接修改 DataProcessor 类：要从 A 方式改成 B 方式？那就把 DataProcessor 的实现代码删掉重写；又要改回 A 方式？那就把 B 方式的代码注释掉（因为预感之后可能还会用到），然后历史提交里找到 A 方式的实现代码粘过来；要根据具体情况决定采用哪种方法？那就写一大堆 if else 来选择某种方法。

这样做行不行呢？行，事实上我之前一直是这么干的。但这样做有两方面问题：

1. DataProcessor 类体积臃肿且改动频繁。由于承载了上述这么多职责，DataProcessor 会膨胀成一个非常臃肿的类，同时正因为职责很多，改动也很频繁。这就留下了很大隐患，增加了改出问题的风险；
2. 不易测试。首先，DataProcessor 由于体积臃肿，本身就不易测试；其次，如果有另一个类 MyService 使用了 DataProcessor，那么对于 MyService 的测试也会受到影响，因为没办法把 DataProcessor mock 掉；

所以，这时候更好的方法是：

• 把 DataProcessor 改成接口；
• 创建一系列实现类，ConcreteDataProcessorA、ConcreteDataProcessorB… 来实现 DataProcessor 接口；
• 重点来了：创建一个 DataProcessorFactory 类，负责创建 DataProcessor 的具体实现类。这就是“简单工厂模式”的体现；

这样就完美地解决了上面的两个问题：

1. 代码按照功能的不同，被分散到了不同组件中：DataProcessor 接口只负责定义方法签名；每个具体的实现类只负责某种特定数据处理方式的实现；DataProcessorFactory 类只负责基于具体情况选择数据处理方式的逻辑（换句话说就是一堆 if else）。这样，每次的改动只会涉及和改动相关的组件，不易出错，提高了可维护性；
2. 如果希望增加对 MyService 类的单元测试，只需要新增一个 MockDataProcessor 类来实现 DataProcessor 接口，然后传给 MyService 类就可以了；

总结一下：

• 如果只需要创建某种特定对象，那么直接 new 就可以，不需要简单工厂模式；
• 如果需要根据具体情况来决定创建哪种具体对象的话，那么简单工厂模式就是一种很好的选择；

换句话说，既然“需要根据具体情况来决定创建哪种具体对象”，那么你的代码里无可避免会出现一堆 if else。而简单工厂模式就是让你可以把这些 if else 单独提取到一个“简单工厂”里，从而提高代码的可维护性。

public class DataProcessorFactory {
	public DataProcessor getDataProcessor(Param someParam) {
		if (someParam ...) {
			return new ConcreteDataProcessorA();
		} else if (someParam ...) {
			return new ConcreteDataProcessorB();
		}
		// 省略若干 else if
	}
}