第3篇：工厂方法模式——把变化隔离到子类
第3篇：工厂方法模式——把变化隔离到子类
摘要：简单工厂违反开闭原则怎么办？工厂方法模式通过将创建逻辑下放到子类，实现了零修改扩展。本文详解其实现、优缺点，并指出其代价——类数量膨胀。
本文是《Java 23 种设计模式：从踩坑到精通》工厂模式长文的扩充短文第3篇，帮助你碎片化掌握核心知识点。
你有没有写过这样的代码？
// 抽象工厂publicinterfaceSenderFactory{SendercreateSender();}// 具体工厂publicclassSmsSenderFactoryimplementsSenderFactory{@OverridepublicSendercreateSender(){returnnewSmsSender();}}publicclassEmailSenderFactoryimplementsSenderFactory{@OverridepublicSendercreateSender(){returnnewEmailSender();}}简单工厂违反开闭原则，怎么办？工厂方法模式给出了优雅的答案：不再用一个工厂类扛所有创建逻辑，而是把“创建”抽象成接口，让每个具体产品都有一个对应的具体工厂。
客户端调用：
SenderFactoryfactory=newSmsSenderFactory();Sendersender=factory.createSender();sender.send("你好，工厂方法！");新增产品时，只需新增一个工厂子类，无需修改任何现有代码——完全符合开闭原则。
你的场景该不该用工厂方法？
| 判断标准 | 是 → 用工厂方法 | 否 → 用其他方式 |
|---|---|---|
| 产品种类多、频繁新增 | ✅ | ❌ |
| 需要遵循开闭原则 | ✅ | ❌ |
| 产品种类少且稳定 | ❌ | 简单工厂就够了 |
| 担心类数量膨胀 | ❌ | 考虑简单工厂 |
一句话总结：用类数量的膨胀换取零修改的扩展，值得还是不值？取决于产品变化的频率。
📖完整长文入口：本文是工厂模式扩充系列的第3篇。如果你想一次性阅读完整内容（含UML、三种工厂对比、框架源码、面试追问等），请查看原长文：
👉 《Java 23 种设计模式：从踩坑到精通 | 工厂模式》
🔗 系列导航：
- 上一篇：第2篇：简单工厂模式——把if-else搬个家
- 下一篇：第4篇：抽象工厂模式——产品族一键创建
- 返回： 《工厂模式·扩充系列》目录
- 返回：《Java 23种设计模式：从踩坑到精通》总目录