第1篇：一段 if-else 的代码，为什么成了“屎山”？
第1篇：一段 if-else 的代码，为什么成了“屎山”？
摘要：一段 if-else 创建对象的代码为何被称为“屎山”？本文从真实痛点出发，揭示工厂模式如何通过封装对象创建过程实现解耦，并附上场景判断表，帮你快速决策何时使用工厂模式。
本文是《Java 23 种设计模式：从踩坑到精通》工厂模式长文的扩充短文第1篇，帮助你碎片化掌握核心知识点。
你有没有写过这样的代码？
if(type.equals("sms")){sender=newSmsSender();}elseif(type.equals("email")){sender=newEmailSender();}elseif(type.equals("wechat")){sender=newWechatSender();}每次新增一种消息渠道，就得在这段if-else后面再加一行。代码越写越长，维护越来越痛苦。更可怕的是，如果有一天SmsSender的构造方法改了，所有写new SmsSender()的地方都得跟着改，一不小心就会漏掉。
工厂模式正是为此而生
它把“创建对象”这件事从业务代码中抽离出来，交给专门的工厂类处理。调用方只需要告诉工厂“我要什么”，工厂返回一个符合接口的对象，至于具体是怎么创建的，调用方根本不需要关心。
你的场景该不该用工厂模式？
| 判断标准 | 是 → 用工厂模式 | 否 → 用其他方式 |
|---|---|---|
| 创建对象的逻辑分散在多处，且经常变化 | ✅ | ❌ |
| 需要根据运行时条件动态决定创建哪种对象 | ✅ | ❌ |
| 希望客户端代码只依赖抽象接口，不依赖具体类 | ✅ | ❌ |
| 产品种类极少（≤2种）且永远不会变 | ❌ | 直接 new 即可 |
一句话总结：创建逻辑复杂、容易变化、需要解耦 → 用工厂模式，告别硬编码。
📖 完整长文入口： 本文是工厂模式扩充系列的第1篇。如果你想一次性阅读完整内容（含UML、三种工厂对比、框架源码、面试追问等），请查看原长文：
👉 《Java 23 种设计模式：从踩坑到精通 | 工厂模式》
🔗 系列导航：
上一篇：无（本篇为首篇）
下一篇：第2篇：简单工厂模式——把if-else搬个家
返回：《工厂模式 · 扩充系列》目录
返回：《Java 23 种设计模式：从踩坑到精通 》总目录