1. 工厂方法模式解耦对象创建的利器第一次接触工厂方法模式是在一个电商系统的开发中。当时我们需要支持多种支付方式支付宝、微信、银联每个支付接口的初始化参数和流程都不相同。直接在业务代码里写new Alipay()、new WechatPay()导致代码高度耦合每次新增支付方式都要修改核心业务逻辑。直到团队里的架构师引入了工厂方法模式才真正体会到面向对象设计中针对接口编程而非实现编程的精髓。工厂方法模式Factory Method Pattern是GoF 23种设计模式中最常用的创建型模式之一。它定义了一个用于创建对象的接口但让子类决定实例化哪一个类。简单来说就是把new操作符从业务代码中抽离出来交给专门的工厂类来处理。这种看似简单的调整却能带来惊人的灵活性——当需要新增产品类型时你只需要扩展新的工厂子类而不用修改任何现有代码。2. 工厂方法模式的核心结构2.1 标准UML类图解析让我们先看一个典型的工厂方法模式类图这里用文字描述替代图形抽象产品Product ↑ 具体产品ConcreteProduct ↑ 抽象创建者Creator → 创建工厂方法() ↑ 具体创建者ConcreteCreator → 实现工厂方法()这个结构中包含四个关键角色抽象产品Product定义产品的接口是所有具体产品类的父类。在我们的支付例子中就是所有支付方式都要实现的IPayment接口。具体产品ConcreteProduct实现抽象产品接口的具体类。比如AlipayPayment、WechatPayment这些具体的支付实现类。抽象创建者Creator声明工厂方法的抽象类/接口它不关心具体创建什么产品只定义创建产品的规范。具体创建者ConcreteCreator实现工厂方法的具体类决定实例化哪个具体产品。比如AlipayFactory的工厂方法就返回new AlipayPayment()。提示在实际开发中Creator不一定非要是抽象类。当默认实现有意义时也可以提供基础的产品创建逻辑。2.2 模式变体与实现方式工厂方法模式在实际应用中有多种实现变体参数化工厂方法通过传入参数决定创建哪种产品。比如public Payment createPayment(String type) { switch(type) { case alipay: return new AlipayPayment(); case wechat: return new WechatPayment(); default: throw new IllegalArgumentException(); } }多态工厂每个具体产品对应一个具体工厂。这是最标准的实现方式// 抽象工厂 interface PaymentFactory { Payment createPayment(); } // 具体工厂 class AlipayFactory implements PaymentFactory { Override public Payment createPayment() { return new AlipayPayment(); } }延迟初始化工厂可以缓存已创建的产品实例实现对象复用class PaymentFactory { private static MapString, Payment cache new HashMap(); public static Payment getPayment(String type) { if(!cache.containsKey(type)) { cache.put(type, createPayment(type)); } return cache.get(type); } }3. 工厂方法模式的典型应用场景3.1 支付系统案例深度剖析让我们回到开头的支付系统案例。没有使用工厂方法之前业务代码可能是这样的public class OrderService { public void pay(String paymentType) { Payment payment; if(alipay.equals(paymentType)) { payment new AlipayPayment(); } else if(wechat.equals(paymentType)) { payment new WechatPayment(); } // 支付逻辑... } }这种实现存在几个严重问题违反开闭原则新增支付方式必须修改OrderService业务逻辑与对象创建耦合难以单元测试因为直接依赖具体实现应用工厂方法模式重构后// 抽象产品 public interface Payment { void pay(BigDecimal amount); } // 具体产品 public class AlipayPayment implements Payment { Override public void pay(BigDecimal amount) { // 支付宝支付实现 } } // 抽象工厂 public interface PaymentFactory { Payment createPayment(); } // 具体工厂 public class AlipayFactory implements PaymentFactory { Override public Payment createPayment() { return new AlipayPayment(); } } // 业务代码 public class OrderService { private PaymentFactory paymentFactory; public OrderService(PaymentFactory factory) { this.paymentFactory factory; } public void pay() { Payment payment paymentFactory.createPayment(); payment.pay(amount); } }重构后的优势显而易见符合开闭原则新增支付方式只需添加新工厂不修改现有代码业务逻辑与对象创建解耦易于测试可以通过Mock工厂注入测试替身3.2 框架设计中的工厂方法工厂方法模式在各种框架中都有广泛应用Spring框架BeanFactory就是典型的工厂方法实现。ApplicationContext作为具体工厂负责创建和管理各种Bean。// Spring中的工厂方法应用 ApplicationContext context new ClassPathXmlApplicationContext(beans.xml); MyService service context.getBean(MyService.class);JDK中的案例java.util.Collection的iterator()方法java.text.NumberFormat的getInstance()方法java.nio.charset.Charset的forName()方法这些API背后都是工厂方法模式的变体实现。4. 工厂方法模式的进阶应用与优化4.1 结合其他设计模式工厂方法模式经常与其他模式配合使用产生更强大的效果工厂方法策略模式当产品有不同的行为变体时可以用策略模式来配置具体行为。interface CompressionStrategy { byte[] compress(byte[] data); } class ZipCompression implements CompressionStrategy { /*...*/ } class CompressionFactory { public CompressionStrategy createCompressor(String type) { switch(type) { case zip: return new ZipCompression(); // 其他压缩算法... } } }工厂方法单例模式确保工厂本身是单例的避免重复创建工厂实例。public enum PaymentFactory { INSTANCE; public Payment createPayment(String type) { // 工厂实现... } }4.2 性能优化考量在性能敏感的场景下工厂方法的实现需要考虑以下优化点对象池技术对于创建成本高的对象如数据库连接工厂可以维护一个对象池。class ConnectionFactory { private static QueueConnection pool new LinkedList(); public static Connection getConnection() { if(pool.isEmpty()) { return createNewConnection(); } return pool.poll(); } public static void releaseConnection(Connection conn) { pool.offer(conn); } }缓存机制对于无状态的对象工厂可以缓存实例避免重复创建。原型模式对于初始化成本高的对象可以克隆原型而非每次都新建。4.3 现代语言中的简化实现在新版Java和其他现代语言中工厂方法的实现可以更加简洁Java 8的函数式工厂MapString, SupplierPayment paymentFactories new HashMap(); paymentFactories.put(alipay, AlipayPayment::new); paymentFactories.put(wechat, WechatPayment::new); Payment payment paymentFactories.get(type).get();Kotlin的伴生对象工厂interface Payment { companion object Factory { fun create(type: String): Payment { return when(type) { alipay - AlipayPayment() else - throw IllegalArgumentException() } } } }5. 工厂方法模式的局限性与替代方案5.1 何时不该使用工厂方法虽然工厂方法模式很强大但并非所有场景都适用简单对象创建如果对象的创建逻辑非常简单直接new可能更清晰。产品类型固定如果系统不太可能扩展新的产品类型引入工厂可能过度设计。性能极端敏感工厂方法调用比直接new多一层间接性在纳秒级优化的场景可能有影响。5.2 相关模式对比与简单工厂对比简单工厂把创建逻辑集中在一个工厂类中工厂方法将创建逻辑分散到各个子工厂工厂方法更符合开闭原则与抽象工厂对比工厂方法创建单一产品抽象工厂创建产品族多个相关产品抽象工厂通常使用工厂方法来实现与依赖注入对比工厂方法是主动获取依赖DI是被动接收依赖现代框架更倾向于使用DI容器5.3 实际项目中的取舍建议根据多年项目经验我总结出以下实践建议渐进式设计初期可以用简单工厂等产品类型增多再重构为工厂方法。结合DI框架在Spring等框架中可以结合Bean方法实现工厂方法。Configuration public class PaymentConfig { Bean Scope(prototype) public Payment alipayPayment() { return new AlipayPayment(); } }文档很重要为工厂类和方法添加清晰的文档说明特别是参数化工厂。考虑可测试性设计工厂接口时要便于mock方便单元测试。在最近的一个微服务项目中我们使用工厂方法模式来创建不同协议HTTP/gRPC的客户端代理。随着协议增加这种设计的优势愈发明显——新增协议实现时业务代码完全不用修改只需要添加新的工厂实现。这大大降低了代码的维护成本也使得团队能够并行开发不同的协议适配器。 
长河君 · 2026/10/26 23:20:04 · 阅读 1.2k 工厂方法模式：解耦对象创建的设计模式实践
1. 工厂方法模式解耦对象创建的利器第一次接触工厂方法模式是在一个电商系统的开发中。当时我们需要支持多种支付方式支付宝、微信、银联每个支付接口的初始化参数和流程都不相同。直接在业务代码里写new Alipay()、new WechatPay()导致代码高度耦合每次新增支付方式都要修改核心业务逻辑。直到团队里的架构师引入了工厂方法模式才真正体会到面向对象设计中针对接口编程而非实现编程的精髓。工厂方法模式Factory Method Pattern是GoF 23种设计模式中最常用的创建型模式之一。它定义了一个用于创建对象的接口但让子类决定实例化哪一个类。简单来说就是把new操作符从业务代码中抽离出来交给专门的工厂类来处理。这种看似简单的调整却能带来惊人的灵活性——当需要新增产品类型时你只需要扩展新的工厂子类而不用修改任何现有代码。2. 工厂方法模式的核心结构2.1 标准UML类图解析让我们先看一个典型的工厂方法模式类图这里用文字描述替代图形抽象产品Product ↑ 具体产品ConcreteProduct ↑ 抽象创建者Creator → 创建工厂方法() ↑ 具体创建者ConcreteCreator → 实现工厂方法()这个结构中包含四个关键角色抽象产品Product定义产品的接口是所有具体产品类的父类。在我们的支付例子中就是所有支付方式都要实现的IPayment接口。具体产品ConcreteProduct实现抽象产品接口的具体类。比如AlipayPayment、WechatPayment这些具体的支付实现类。抽象创建者Creator声明工厂方法的抽象类/接口它不关心具体创建什么产品只定义创建产品的规范。具体创建者ConcreteCreator实现工厂方法的具体类决定实例化哪个具体产品。比如AlipayFactory的工厂方法就返回new AlipayPayment()。提示在实际开发中Creator不一定非要是抽象类。当默认实现有意义时也可以提供基础的产品创建逻辑。2.2 模式变体与实现方式工厂方法模式在实际应用中有多种实现变体参数化工厂方法通过传入参数决定创建哪种产品。比如public Payment createPayment(String type) { switch(type) { case alipay: return new AlipayPayment(); case wechat: return new WechatPayment(); default: throw new IllegalArgumentException(); } }多态工厂每个具体产品对应一个具体工厂。这是最标准的实现方式// 抽象工厂 interface PaymentFactory { Payment createPayment(); } // 具体工厂 class AlipayFactory implements PaymentFactory { Override public Payment createPayment() { return new AlipayPayment(); } }延迟初始化工厂可以缓存已创建的产品实例实现对象复用class PaymentFactory { private static MapString, Payment cache new HashMap(); public static Payment getPayment(String type) { if(!cache.containsKey(type)) { cache.put(type, createPayment(type)); } return cache.get(type); } }3. 工厂方法模式的典型应用场景3.1 支付系统案例深度剖析让我们回到开头的支付系统案例。没有使用工厂方法之前业务代码可能是这样的public class OrderService { public void pay(String paymentType) { Payment payment; if(alipay.equals(paymentType)) { payment new AlipayPayment(); } else if(wechat.equals(paymentType)) { payment new WechatPayment(); } // 支付逻辑... } }这种实现存在几个严重问题违反开闭原则新增支付方式必须修改OrderService业务逻辑与对象创建耦合难以单元测试因为直接依赖具体实现应用工厂方法模式重构后// 抽象产品 public interface Payment { void pay(BigDecimal amount); } // 具体产品 public class AlipayPayment implements Payment { Override public void pay(BigDecimal amount) { // 支付宝支付实现 } } // 抽象工厂 public interface PaymentFactory { Payment createPayment(); } // 具体工厂 public class AlipayFactory implements PaymentFactory { Override public Payment createPayment() { return new AlipayPayment(); } } // 业务代码 public class OrderService { private PaymentFactory paymentFactory; public OrderService(PaymentFactory factory) { this.paymentFactory factory; } public void pay() { Payment payment paymentFactory.createPayment(); payment.pay(amount); } }重构后的优势显而易见符合开闭原则新增支付方式只需添加新工厂不修改现有代码业务逻辑与对象创建解耦易于测试可以通过Mock工厂注入测试替身3.2 框架设计中的工厂方法工厂方法模式在各种框架中都有广泛应用Spring框架BeanFactory就是典型的工厂方法实现。ApplicationContext作为具体工厂负责创建和管理各种Bean。// Spring中的工厂方法应用 ApplicationContext context new ClassPathXmlApplicationContext(beans.xml); MyService service context.getBean(MyService.class);JDK中的案例java.util.Collection的iterator()方法java.text.NumberFormat的getInstance()方法java.nio.charset.Charset的forName()方法这些API背后都是工厂方法模式的变体实现。4. 工厂方法模式的进阶应用与优化4.1 结合其他设计模式工厂方法模式经常与其他模式配合使用产生更强大的效果工厂方法策略模式当产品有不同的行为变体时可以用策略模式来配置具体行为。interface CompressionStrategy { byte[] compress(byte[] data); } class ZipCompression implements CompressionStrategy { /*...*/ } class CompressionFactory { public CompressionStrategy createCompressor(String type) { switch(type) { case zip: return new ZipCompression(); // 其他压缩算法... } } }工厂方法单例模式确保工厂本身是单例的避免重复创建工厂实例。public enum PaymentFactory { INSTANCE; public Payment createPayment(String type) { // 工厂实现... } }4.2 性能优化考量在性能敏感的场景下工厂方法的实现需要考虑以下优化点对象池技术对于创建成本高的对象如数据库连接工厂可以维护一个对象池。class ConnectionFactory { private static QueueConnection pool new LinkedList(); public static Connection getConnection() { if(pool.isEmpty()) { return createNewConnection(); } return pool.poll(); } public static void releaseConnection(Connection conn) { pool.offer(conn); } }缓存机制对于无状态的对象工厂可以缓存实例避免重复创建。原型模式对于初始化成本高的对象可以克隆原型而非每次都新建。4.3 现代语言中的简化实现在新版Java和其他现代语言中工厂方法的实现可以更加简洁Java 8的函数式工厂MapString, SupplierPayment paymentFactories new HashMap(); paymentFactories.put(alipay, AlipayPayment::new); paymentFactories.put(wechat, WechatPayment::new); Payment payment paymentFactories.get(type).get();Kotlin的伴生对象工厂interface Payment { companion object Factory { fun create(type: String): Payment { return when(type) { alipay - AlipayPayment() else - throw IllegalArgumentException() } } } }5. 工厂方法模式的局限性与替代方案5.1 何时不该使用工厂方法虽然工厂方法模式很强大但并非所有场景都适用简单对象创建如果对象的创建逻辑非常简单直接new可能更清晰。产品类型固定如果系统不太可能扩展新的产品类型引入工厂可能过度设计。性能极端敏感工厂方法调用比直接new多一层间接性在纳秒级优化的场景可能有影响。5.2 相关模式对比与简单工厂对比简单工厂把创建逻辑集中在一个工厂类中工厂方法将创建逻辑分散到各个子工厂工厂方法更符合开闭原则与抽象工厂对比工厂方法创建单一产品抽象工厂创建产品族多个相关产品抽象工厂通常使用工厂方法来实现与依赖注入对比工厂方法是主动获取依赖DI是被动接收依赖现代框架更倾向于使用DI容器5.3 实际项目中的取舍建议根据多年项目经验我总结出以下实践建议渐进式设计初期可以用简单工厂等产品类型增多再重构为工厂方法。结合DI框架在Spring等框架中可以结合Bean方法实现工厂方法。Configuration public class PaymentConfig { Bean Scope(prototype) public Payment alipayPayment() { return new AlipayPayment(); } }文档很重要为工厂类和方法添加清晰的文档说明特别是参数化工厂。考虑可测试性设计工厂接口时要便于mock方便单元测试。在最近的一个微服务项目中我们使用工厂方法模式来创建不同协议HTTP/gRPC的客户端代理。随着协议增加这种设计的优势愈发明显——新增协议实现时业务代码完全不用修改只需要添加新的工厂实现。这大大降低了代码的维护成本也使得团队能够并行开发不同的协议适配器。