工厂模式这名字相信只要是写代码的多少都听过。网上讲它的文章浩如烟海但不少人看完还是一头雾水代码里该用的时候想不起来不该用的时候又硬套。我最早接触这个模式时也犯过迷糊觉得不就一个new换个地方写吗后来在实际项目里踩了几次坑才慢慢咂摸出味道——工厂模式不是把new挪个位置那么简单它背后是“创建逻辑”与“使用逻辑”的一场彻底分离。这篇文章我就用大白话把工厂模式掰开揉碎。不讲虚的直接上代码看它到底解决什么问题、三个变体怎么选、实战里怎么落地还有那些文档里不会写的坑。不管是刚入行的新人还是写了几年业务代码想夯实基础的老兵看完这篇应该都能把工厂模式用得明明白白。1. 工厂模式到底在解决什么问题先别急着看代码想清楚“为什么需要工厂模式”比记住代码重要一百倍。工厂模式的英文叫Factory Pattern在GoF的《设计模式》里归类为创建型模式。创建型模式一共五个单例、工厂、抽象工厂、建造者、原型它们全都在回答同一个问题对象怎么被创建出来。你可能觉得创建对象不是天经地义的吗Java里写个new UserService()Python里写个UserService()这不就完了问题恰恰出在这个new上。1.1 “new”字背后的耦合危机写代码最怕什么怕改。需求一变代码跟着要动动的越多出Bug概率越大。new这个关键字的问题在于它把“创建谁”这件事硬编码在了调用方代码里。举个例子。假设现在要做个支付系统第一版只支持微信支付你在业务代码里直接写了WechatPay pay new WechatPay(); pay.pay(amount);代码跑得好好的。后来产品经理过来说要加支付宝。那这个new WechatPay()的地方得改吧改成new Alipay()同时这个类的构造方法可能还不一样参数多了个appId你得把这个初始化逻辑也补上。再后来要加银联、加PayPal、加各种各样的海外支付渠道……每次新增所有调用点全部沦陷全要动一遍。这还只是改代码的问题。更深层次的隐患是你在业务层写了new WechatPay()业务层就依赖了一个具体的实现类。这种依赖直接违背了设计原则里的“依赖倒置”高层模块不该依赖低层模块应该依赖抽象。1.2 工厂模式的核心思想创建与使用分离工厂模式的思想极其朴素创建对象这件事从调用方手里拿走交给一个单独的“工厂”去做。你来餐厅吃饭你不会自己下厨对吧你只需要在菜单上点一下后厨做什么你别管做出来什么你只管吃。这个后厨就是工厂菜单就是工厂方法你手里的筷子才是业务逻辑。有了工厂之后上面的支付例子就变成了Pay pay PayFactory.create(ChannelEnum.WECHAT); pay.pay(amount);业务方看到的是一个Pay接口它不关心create内部是new了WechatPay还是Alipay。以后再加新渠道只要改工厂内部业务代码一行都不用动。这就是工厂模式最本质的价值把变化收敛在一个地方让稳定的一方依赖抽象而不是依赖具体实现。这个概念说起来简单但真要选对工厂模式的具体形态还是有门道的。下面我把三个常见变体一个一个拆开讲。2. 三种工厂形式怎么选才不翻车很多初学者卡在“工厂模式到底有几种”这个问题上。GoF原书里只提了工厂方法和抽象工厂但实际工程中大家习惯把“简单工厂”也算进来。三个我都讲讲重点说清楚它们的血缘关系和适 
长河君 · 2026/10/14 23:28:06 · 阅读 1.2k 工厂模式怎么选？三种变体与实战避坑指南
工厂模式这名字相信只要是写代码的多少都听过。网上讲它的文章浩如烟海但不少人看完还是一头雾水代码里该用的时候想不起来不该用的时候又硬套。我最早接触这个模式时也犯过迷糊觉得不就一个new换个地方写吗后来在实际项目里踩了几次坑才慢慢咂摸出味道——工厂模式不是把new挪个位置那么简单它背后是“创建逻辑”与“使用逻辑”的一场彻底分离。这篇文章我就用大白话把工厂模式掰开揉碎。不讲虚的直接上代码看它到底解决什么问题、三个变体怎么选、实战里怎么落地还有那些文档里不会写的坑。不管是刚入行的新人还是写了几年业务代码想夯实基础的老兵看完这篇应该都能把工厂模式用得明明白白。1. 工厂模式到底在解决什么问题先别急着看代码想清楚“为什么需要工厂模式”比记住代码重要一百倍。工厂模式的英文叫Factory Pattern在GoF的《设计模式》里归类为创建型模式。创建型模式一共五个单例、工厂、抽象工厂、建造者、原型它们全都在回答同一个问题对象怎么被创建出来。你可能觉得创建对象不是天经地义的吗Java里写个new UserService()Python里写个UserService()这不就完了问题恰恰出在这个new上。1.1 “new”字背后的耦合危机写代码最怕什么怕改。需求一变代码跟着要动动的越多出Bug概率越大。new这个关键字的问题在于它把“创建谁”这件事硬编码在了调用方代码里。举个例子。假设现在要做个支付系统第一版只支持微信支付你在业务代码里直接写了WechatPay pay new WechatPay(); pay.pay(amount);代码跑得好好的。后来产品经理过来说要加支付宝。那这个new WechatPay()的地方得改吧改成new Alipay()同时这个类的构造方法可能还不一样参数多了个appId你得把这个初始化逻辑也补上。再后来要加银联、加PayPal、加各种各样的海外支付渠道……每次新增所有调用点全部沦陷全要动一遍。这还只是改代码的问题。更深层次的隐患是你在业务层写了new WechatPay()业务层就依赖了一个具体的实现类。这种依赖直接违背了设计原则里的“依赖倒置”高层模块不该依赖低层模块应该依赖抽象。1.2 工厂模式的核心思想创建与使用分离工厂模式的思想极其朴素创建对象这件事从调用方手里拿走交给一个单独的“工厂”去做。你来餐厅吃饭你不会自己下厨对吧你只需要在菜单上点一下后厨做什么你别管做出来什么你只管吃。这个后厨就是工厂菜单就是工厂方法你手里的筷子才是业务逻辑。有了工厂之后上面的支付例子就变成了Pay pay PayFactory.create(ChannelEnum.WECHAT); pay.pay(amount);业务方看到的是一个Pay接口它不关心create内部是new了WechatPay还是Alipay。以后再加新渠道只要改工厂内部业务代码一行都不用动。这就是工厂模式最本质的价值把变化收敛在一个地方让稳定的一方依赖抽象而不是依赖具体实现。这个概念说起来简单但真要选对工厂模式的具体形态还是有门道的。下面我把三个常见变体一个一个拆开讲。2. 三种工厂形式怎么选才不翻车很多初学者卡在“工厂模式到底有几种”这个问题上。GoF原书里只提了工厂方法和抽象工厂但实际工程中大家习惯把“简单工厂”也算进来。三个我都讲讲重点说清楚它们的血缘关系和适