一文彻底搞明白工厂方法模式

大家好，欢迎来到IT知识分享网。

本篇讲解Java设计模式中的工厂方法模式，分为定义、模式应用前案例、结构、模式应用后案例、适用场景、模式可能存在的困惑和本质探讨7个部分。

定义

工厂方法模式定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类。

简单工厂在实际应用中也经常用到，它是工厂方法的一种特例。

在新的分类方式中，工厂方法模式被划分至类之间的交互类别中，其简化的是调用方与对象创建方之间的交互

模式应用前案例

在工厂方法模式以及后面的抽象工厂模式中，我们选择一个不同格式文件导出的案例。

先来看一下未使用工厂方法模式之前的代码，如下所示。
声明一个文件导出的接口，以及分别定义PDF和CSV两个具体实现的类。

public interface IExporter {//声明一个文件导出接口 void export(String data); } public class CSVExporter implements IExporter {//CSV文件格式导出 @Override public void export(String data) { System.out.println("Exporting data to CSV: " + data); } } public class PDFExporter implements IExporter {//PDF文件格式导出 @Override public void export(String data) { System.out.println("Exporting data to PDF: " + data); } } 

调用方代码如下：

public class Client {//调用方代码 private static IExporter getExporter(String type){ if (type.equals("PDF")) { return new PDFExporter(); } else if (type.equals("CSV")) { return new CSVExporter(); } else { throw new IllegalArgumentException("Invalid exporter type."); } } public static void main(String[] args) { IExporter pdfExporter = getExporter("PDF"); pdfExporter.export("Sample PDF Data"); IExporter csvExporter = getExporter("CSV"); csvExporter.export ("sample Csv Data"); } }

上述代码的主要问题在于调用方与每一种格式的具体实现类是紧耦合关系。实现类如果有变化或扩展，调用方都可能需要跟着变更，违背OCP开闭原则。

结构

对于工厂方法模式来说，由简到难又可以分成简单工厂模式、工厂方法模式和工厂中的工厂三种方式。

1.简单工厂模式

简单工厂模式是工厂方法模式的一种特例。在该模式中，工厂类使用一个简单的类，未使用接口实现或继承等家族方式。

简单工厂模式的主要问题在于SimpleFactory类中需要维护分支判断逻辑，如果后续Product实现类需要扩展，那么SimpleFactory类需要一同扩展，有些违背“对扩展开放、对修改关闭”的OCP原则。后面的工厂方法模式则主要为了解决该问题。

简单工厂的示例代码实现如下：

public interface Product { void func(); } public class ConcreteProductA implements Product { @Override public void func() { System.out.println("Product A is funcing..."); } } public class ConcreteProductB implements Product { @Override public void func() { System.out.println("Product B is funcing..."); } } public class SimpleFactory { public Product createProduct(String type) { if ("A".equalsIgnoreCase(type)) { return new ConcreteProductA(); } else if ("B".equalsIgnoreCase(type)) { return new ConcreteProductB(); } return null; } } public class Client { public static void main(String[] args) { SimpleFactory factory = new SimpleFactory(); Product p1 = factory.createProduct("A"); Product p2 = factory.createProduct("B"); p1.func(); p2.func(); } } 

2.工厂方法模式

为了解决简单工厂模式中的违背OCP原则的问题，工厂方式模式将SimpleFactory工厂类扩展成一个工厂类家族（可使用接口或继承实现），这样分支判断逻辑可以不用在工厂类中实现。

但是，这样也带来了后面的问题，即调用方需要知晓工厂类家族中的每一个具体实现类，两者是紧耦合关系。

此外，后续扩展一种文件格式，工厂实现类也需要一并扩展，违背OCP开闭原则。

工厂方法模式的示例代码实现如下：

public interface Product { void func(); } public class ConcreteProductA implements Product { @Override public void func() { System.out.println("Product A is funcing..."); } } public class ConcreteProductB implements Product { @Override public void func() { System.out.println("Product B is funcing..."); } } public abstract class Factory { public abstract Product factoryMethod(); public void doSomething(){ Product p = factoryMethod(); p.func(); } } public class ConcreteFactoryA extends Factory { @Override public Product factoryMethod() { return new ConcreteProductA(); } } public class ConcreteFactoryB extends Factory { @Override public Product factoryMethod() { return new ConcreteProductA(); } } public class Client { public static void main(String[] args) { //使用 ConcreteFactory创建 Factory对象 Factory fa = new ConcreteFactoryA(); Product pa = fa.factoryMethod(); pa.func(); Factory fb = new ConcreteFactoryB(); Product pb = fa.factoryMethod(); pb.func(); } } 

3.工厂方法+简单工厂模式（工厂中的工厂）

为了解决工厂方式模式中的调用方和工厂家族类紧耦合的问题，可以前面再增加一个简单工厂ExporterFactoryMap类，由它屏蔽调用方与具体工厂实现类之间的交互问题。

模式应用后案例

接下来继续上面的文件导出案例，分别使用简单工厂模式、工厂方式模式和工厂中的工厂来进行实现。

1.简单工厂模式

声明一个文件导出的接口，以及分别定义PDF和CSV两个具体实现的类。

public interface IExporter {//文件导出接口 void export(String data); } public class CSVExporter implements IExporter {//CSV格式文件导出 @Override public void export(String data) { System.out.println("Exporting data to CSV: " + data); } } public class PDFExporter implements IExporter {//PDF文件格式导出 @Override public void export(String data) { System.out.println("Exporting data to PDF: " + data); } } 

然后，定义一个简单工厂类。可以发现，该工厂类中含有具体文件类的分支判断逻辑。缺点在于如果后续文件导出文件有扩展，工厂类一并扩展。

public class ExporterFactory {//简单工厂SimpleFactory public static IExporter createExporter(String type) { if (type.equals("PDF")) { return new PDFExporter(); } else if (type.equals("CSV")) { return new CSVExporter(); } else { throw new IllegalArgumentException("Invalid exporter type."); } } } 

调用方代码如下。

public class Client {//简单工厂SimpleFactory的应用 private static IExporter getExporter(String type){ if (type.equals("PDF")) { return ExporterFactory.createExporter("PDF"); } else if (type.equals("CSV")) { return ExporterFactory.createExporter ("CSV"); } else { throw new IllegalArgumentException("Invalid exporter type."); } } public static void main(String[] args) { // 使用简单工厂创建并使用不同类型的导出对象 IExporter pdfExporter = getExporter("PDF"); pdfExporter.export("Sample PDF Data"); IExporter csvExporter = getExporter("CSV"); csvExporter.export ("sample Csv Data") ; } } 

2.工厂方法模式

声明一个文件导出的接口，以及分别定义PDF和CSV两个具体实现的类。

public interface IExporter {//文件导出接口 void export(String data); } public class CSVExporter implements IExporter {//CSV文件格式导出 @Override public void export(String data) { System.out.println("Exporting data to CSV: " + data); } } public class PDFExporter implements IExporter {//PDF文件格式导出 @Override public void export(String data) { System.out.println("Exporting data to PDF: " + data); } } 

然后，由简单工厂模式中的一个类扩展成一个家族，该案例中具体包括一个工厂接口以及CSV和PDF两个文件格式的工厂类。

public interface IExporterFactory {//工厂接口 // 工厂创建方法 public IExporter createExporter(); } public class CSVExporterFactory implements IExporterFactory {//CSV文件格式工厂 @Override public IExporter createExporter() { return new CSVExporter(); } } class PdfExporterFactory implements IExporterFactory {//PDF文件格式工厂 @Override public IExporter createExporter() { return new PDFExporter(); } } 

工厂方法的调用方代码如下。可以发现，原来简单工厂模式中的分支判断逻辑已经移动到调用方代码中实现。这样一来，调用方和工厂的接口和实现类都是紧耦合关系。

public class Client {//工厂方法的调用方 private static IExporterFactory getExporterFactory(String type) { if (type.equals("PDF")) { return new PdfExporterFactory(); } else if (type.equals("CSV")) { return new CSVExporterFactory(); } else { throw new IllegalArgumentException("Invalid exporter type."); } } public static void main(String[] args){ String type = "PDF"; IExporterFactory factory = getExporterFactory(type); IExporter exporter = factory.createExporter(); String data = "test data"; exporter.export(data); } } 

3.工厂方法+简单工厂模式（工厂中的工厂）

为了解决工厂方式模式中的上述紧耦合问题，再增加一个简单工厂，代码如下所示。

public class ExporterFactoryMap {//工厂类的简单工厂 private static final Map<String, IExporterFactory> cachedFactories = new HashMap<String, IExporterFactory>(); static { cachedFactories.put("PDF", new PdfExporterFactory()); cachedFactories.put("CSV", new CSVExporterFactory()); } public static IExporterFactory getExporterFactory(String type){ return cachedFactories.get(type.toUpperCase()); } } 

客户端代码修改如下。可以看出，现在客户端不需要知晓具体的工厂类，只需要知晓ExporterFactoryMap这个简单工厂类即可。

public class Client {//工厂方法模式+简单工厂=工厂的工厂 public static void main(String[] args){ String type = "PDF"; IExporterFactory factory = ExporterFactoryMap.getExporterFactory(type); IExporter exporter = factory.createExporter(); String data = "test data2"; exporter.export(data); } }

适用场景

工厂方法模式的适用场景包括：

1、代码中存在条件分支的情形下，比如根据不同文件格式、不同支付方式等

2、存在创建家族类的情形下，比如接口类和多个实现类、抽象类和多个实现类、父类和多个子类的场景下

模式可能存在的困惑

困惑1：简单工厂模式和工厂方法+简单工厂模式相比，两者最后通过简单工厂类封装了分支判断逻辑，好像并没有什么优势。

因为上面的示例代码比较简单。如果创建对象的逻辑比较复杂，而且实现类又比较多。如果这些逻辑都放在简单工厂模式中的SimpleFactory类中，这个类的职责过多，后续维护困难。

相比较而言，工厂方法+简单工厂模式，将复杂对象的创建逻辑分散到不同的工厂实现类中，这样每个类职责更加单一。

困惑2：不论哪种方法，好像都没有完全消除分支判断逻辑，不同的模式仅是将其转移到不同的地方？

确实是这样。分支逻辑不可能完全消除。但是，有一点需要格外注意，分支逻辑尽可能不要放在核心类中，而是要放到支撑类当中。核心类要尽可能保持稳定性。

困惑3：编程中的OCP开闭原则，对扩展开放和对修改封闭，放到工厂方法模式中的任一模式中，好像都不符合要求。

简单工厂模式中，如果文件格式扩展，简单工厂类需要一并扩展；在工厂方法模式中，如果文件格式扩展，工厂实现类需要一并扩展；在工厂方法+简单工厂模式中，如果文件格式扩展，工厂实现类和简单工厂类都要一并扩展。严格按照OCP原则来说，都不符合要求。

实际上，完全做到OCP原则几乎是不可能的。即便使用反射+配置文件的方式。不同的文件格式放在配置文件中实现，后续配置文件也需要扩展。

OCP原则更多讲的是如何以最小的成本实现扩展。具体到设计模式中，大家要遵循在扩展时核心类不要修改，支撑类可以修改的原则。

本质

在未使用工厂模式之前，传统创建对象都是采用new方式，这种方式的主要缺点在于调用方和被调用方两者直接依赖，耦合性强。

工厂模式的本质也是要为调用方创建对象。那么它最优先实现的一点即是要实现与调用方交互尽可能简单的情况下，满足调用方获取对象的需求。

在这个要求下，简单工厂模式和工厂方法+简单工厂模式，对调用方暴露的信息是差不多一致的。选择哪种方式最终取决于创建对象的逻辑是否复杂。