第1篇：一段 if-else 的代码，为什么成了“屎山”？

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