工厂方法模式把创建延迟到子类简单工厂把所有产品的创建逻辑塞进一个工厂类新增产品必须修改工厂。工厂方法模式换了个思路不再用一个工厂创建所有产品而是为每种产品定义一个工厂让子类决定创建什么。这就是 GoF 23 种设计模式中的工厂方法模式。它比简单工厂更符合开闭原则代价是类的数量成倍增加。结构工厂方法模式包含四个角色抽象产品Product定义产品的接口具体产品Concrete Product实现产品接口的具体类抽象工厂Creator声明工厂方法返回抽象产品具体工厂Concrete Creator实现工厂方法返回具体产品抽象工厂中通常还包含一些依赖产品的业务逻辑这些逻辑调用工厂方法获取产品对象但不关心具体是哪个产品。代码实现还是用支付作为例子。抽象产品publicinterfacePayment{voidpay(doubleamount);}具体产品publicclassAliPayimplementsPayment{Overridepublicvoidpay(doubleamount){System.out.println(支付宝支付amount);}}publicclassWechatPayimplementsPayment{Overridepublicvoidpay(doubleamount){System.out.println(微信支付amount);}}抽象工厂publicabstractclassPaymentFactory{// 工厂方法由子类实现publicabstractPaymentcreatePayment();// 业务逻辑依赖工厂方法创建的产品publicvoidprocessPayment(doubleamount){PaymentpaymentcreatePayment();// 可以在这里加统一的处理逻辑比如日志、校验payment.pay(amount);}}具体工厂publicclassAliPayFactoryextendsPaymentFactory{OverridepublicPaymentcreatePayment(){returnnewAliPay();}}publicclassWechatPayFactoryextendsPaymentFactory{OverridepublicPaymentcreatePayment(){returnnewWechatPay();}}调用方publicclassClient{publicstaticvoidmain(String[]args){PaymentFactoryfactorynewAliPayFactory();factory.processPayment(100);}}调用方只依赖PaymentFactory抽象类和Payment接口完全不接触具体类。与简单工厂的关键区别简单工厂是一个工厂类创建所有产品工厂方法把创建延迟到子类每种产品对应一个工厂类。新增一种支付方式时简单工厂修改PaymentFactory的switch加一个case。工厂方法新增UnionPayFactory类不动任何已有代码。前者违反开闭原则后者符合。这是工厂方法最核心的优势。对比维度简单工厂工厂方法工厂类数量1 个N 个每个产品一个新增产品修改工厂类新增工厂类开闭原则违反符合代码复杂度低中适用场景产品少且稳定产品多且需扩展抽象工厂中的业务逻辑工厂方法不只是“返回一个对象”。抽象工厂里通常还有依赖产品的业务方法这些方法调用工厂方法获取产品再执行通用逻辑。publicabstractclassPaymentFactory{publicabstractPaymentcreatePayment();publicvoidprocessPayment(doubleamount){// 通用逻辑校验、日志、记录时间System.out.println(开始处理支付...);PaymentpaymentcreatePayment();payment.pay(amount);System.out.println(支付处理完成);}}子类只需要实现createPayment()通用的处理流程由抽象类统一定义。这是模板方法模式和工厂方法模式的经典组合——抽象类定义流程骨架子类填充具体产品的创建逻辑。何时用工厂方法产品种类会持续扩展。如果未来会不断增加新的产品类型工厂方法比简单工厂更合适因为扩展成本更低。需要把创建和使用分离到不同层次。框架设计常用工厂方法让框架定义抽象工厂具体产品由使用方通过子类提供。产品创建有复杂逻辑。每个产品可能有不同的初始化步骤放在各自的工厂类里更清晰。不希望调用方依赖具体产品类。调用方只认识抽象工厂和抽象产品具体类完全隐藏。何时不用产品种类少且稳定。如果只有两三种产品未来也不会增加简单工厂足够工厂方法反而增加了不必要的类。不需要扩展点。如果整个系统只有一处地方需要创建对象抽象出工厂类意义不大。类和接口已经很多了。工厂方法会让类数量翻倍如果项目本身结构复杂要谨慎权衡。在 Spring 中的体现Spring 的FactoryBean接口是工厂方法模式的一个变体publicinterfaceFactoryBeanT{TgetObject()throwsException;Class?getObjectType();booleanisSingleton();}getObject()就是工厂方法。你可以通过实现FactoryBean来定制复杂对象的创建过程Spring 容器在getBean()时会调用getObject()返回真正的对象。Spring 的BeanFactory体系本身也是工厂模式的集大成者。BeanFactory是抽象工厂XmlBeanFactory、AnnotationConfigApplicationContext等是具体工厂它们负责创建和管理 Bean。一个容易踩的坑抽象工厂里的工厂方法不要在构造方法或字段初始化时调用。因为子类构造方法执行时父类构造方法先执行此时子类的字段还没初始化createPayment()可能拿到不完整的对象。publicabstractclassPaymentFactory{privatePaymentdefaultPaymentcreatePayment();// ❌ 危险publicabstractPaymentcreatePayment();}正确做法是在业务方法中调用而不是在构造阶段。总结维度说明核心思想定义创建对象的接口让子类决定实例化哪个类角色抽象产品、具体产品、抽象工厂、具体工厂与简单工厂的区别每种产品一个工厂扩展时新增类而非修改已有代码优点符合开闭原则创建与使用分离职责清晰缺点类数量增加抽象层次提高典型组合与模板方法模式配合抽象类定义流程子类实现创建Spring 体现FactoryBean、BeanFactory体系工厂方法模式解决的是“新增产品要改工厂”的问题代价是多了一层继承体系。当产品种类会持续增长或者需要把创建逻辑下放到子类时它是比简单工厂更合适的选择。