工厂方法模式实战：告别“加个支付方式就改崩旧代码”

1. 一改就崩的根源：创建对象的代码散落在业务里

1.1 这次“加功能”是怎么把我拖下水的

你有没有过这种开发直觉：产品说“结算那边再支持一种支付方式，工作量不大吧？”你心想，这不就是把以前的支付宝、微信，再复制一份吗？结果打开代码一看，复制是敢复制，没人敢保证不把旧的弄崩。

我之前维护过一套老订单系统，里面支持支付宝、微信、银行卡三种支付渠道。表面上看，渠道的定义还挺干净的，有一个 PayClient 接口，三种实现类。但问题不在实现类，而在“用这些实现类的地方”。新增一个支付方式之前，我得先全文搜索 new AlipayClient、new WechatClient 出现在哪，然后顺着调用链逐个去补分支。搜完发现，支付模块的分支还算集中，可退款、对账、回调通知这些模块里全各有一份类似的“选渠道”逻辑。有的用 if (payType == 1)，有的用 switch，还有个模块直接写 if (payType.equals("ALIPAY"))——同一个支付类型，光是字符串表示就有三种。

为了塞进新支付方式，我在这些地方分别加了 else if 和 case，走了一遍全量回归。看着像是只加了新功能，可实际上所有旧渠道的业务路径都被我重新执行了一遍。就在提测前一天，同事告诉我：银行卡退款回调怎么没通知到？我排查了很久，最后发现是 回调通知处理 里那个新分支的参数顺序写错了，而且那段代码为了兼顾新渠道，把旧渠道的一个默认值给覆盖了。新功能没出彩，旧功能先崩了一地。

这个经历特别应景：为什么加个新功能，要把旧代码改个底朝天？因为我们绝大多数业务代码里，“创建对象”这件事和“选择对象类型”这件事紧紧缠在一起。加一种新实现，不光是新增一个类，还要把凡是知道“有哪几种实现”的代码全翻出来改一遍。旧代码不是故意跟你作对，而是你压根没给“新增实现”留出独立位置，它只能往旧逻辑里硬塞。

1.2 还原现场：代码是怎么一步步被“焊死”的

我简化一下当时的代码，大家应该都不陌生：

java复制public class PayService {

    public void pay(Order order) {
        PayClient client;

        if (order.getPayType() == 1) {
            client = new AlipayClient(order.getAmount());
        } else if (order.getPayType() == 2) {
            client = new WechatClient(order.getAmount());
        } else if (order.getPayType() == 3) {
            client = new CardClient(order.getAmount(), order.getCardNo());
        } else {
            throw new UnsupportedOperationException("不支持的支付方式");
        }

        client.pay();
    }
}

这段代码里，PayClient 是一个抽象接口，三种实现类分别是支付宝、微信、银行卡。表面上看，变量类型写的是 PayClient，好像已经依赖抽象了。可仔细看，真正决定对象的 new AlipayClient、new WechatClient、new CardClient 还是把具体类型写死在流程里了。

“依赖抽象”这件事，最容易骗人的就是这里：局部变量可以用抽象类型来接，但创建动作里只要有 new，就绕不开具体实现类。而且更麻烦的是，这个 if-else 不是只出现在 PayService.pay() 里。退款模块可能有：

java复制if (order.getPayType() == 1) {
    refundClient = new AlipayClient(order.getAmount());
} else if (order.getPayType() == 2) {
    refundClient = new WechatClient(order.getAmount());
}

对账模块可能有：

java复制switch (order.getPayType()) {
    case 1:
        checker = new AlipayClient(order.getAmount());
        break;
    case 2:
        checker = new WechatClient(order.getAmount());
        break;
    ...
}

回调模块甚至有更夸张的：

java复制if (callback.getChannel().equals("ALI")) {
    handler = new AlipayHandler(...);
} else if (callback.getChannel().equals("WX")) {
    handler = new WechatHandler(...);
}

这些散落的创建点，导致即使只加一种新支付方式，也会触碰所有模块的旧代码。我把这种状态叫“对象类型焊死在调用方”。一旦 PayType 这种变化频繁的东西出现在创建代码里，它就会像一个毒源，沿着 if-else 把所有模块全部感染。你加的每个新分支，都不是在建设一个新功能，而是在旧代码里刨坑。

1.3 为什么这不是“代码脏一点”那么简单

很多人第一反应是：这不就是代码写得烂吗？把 if-else 清理一下不就行了？

我一开始也这么想，于是我把多个模块里重复的支付类型判断抽到一个工具类，统一收口。结果呢？确实少改了几处，但那个工具类变成了一个超级 switch，每次加渠道都要去动它，改着改着它自己就成了全镇最庞大的“屎山”。后来我逐渐想明白，问题本质不是代码脏不脏，而是创建对象这个职责没有独立出来。

业务代码既要处理业务规则，又要负责“根据不同条件决定创建哪个具体类”，这是两个完全不同的关注点。业务代码关心的是“支付完成后该走什么流程”，它本来不需要关心“支付宝这个类是怎么 new 出来的”。可我们把这些职责揉在一起，等于让所有用到 PayClient 的业务模块，都背上了一个沉重的负担：它们必须知道市场上现在有哪几种 PayClient、各自的 type 是多少、构造函数参数分别是什么。

这样所有关心支付渠道的模块，都是“创建知识”的耦合点。渠道数量少的时候，这些耦合还能靠人肉维护控制住；渠道一旦开始增加，新增功能就是在所有耦合点上打补丁。旧代码底朝天，只是早晚的问题。

2. 一次真实重构：从“手写 new”到“按订单类型选工厂”

要解决这个问题，我当时选择的思路就是 工厂方法模式。但我不是生搬硬套设计模式，而是先做了一次真实的收口重构。整个过程可以分成四步，每一步都有明确目的。

2.1 先把“产品”整理成统一接口

任何模式的引入，前提是产品本身得有一个站得住的抽象。如果你代码里连 PayClient 这种共同接口都没有，那第一步不是建工厂，而是整理产品等级结构。

在我的案例里，PayClient 已经存在，它定义了支付、退款、查询等核心动作。支付宝、微信、银行卡都实现了这个接口。但问题在于，创建它们的方式太随意了：new AlipayClient(amount) 是把金额传进构造函数；而 CardClient 还要额外传卡号；以后云闪付可能还需要传手机号、商家号、证书路径。每个实现类的构造参数越来越不一样，直接在各业务模块里各自 new，一旦多个参数组合有调整，所有调用都会跟着改。

所以我把产品实现类的构造方式先收敛了一下，让实现类内部去消化它自己需要的参数，而不是逼着调用方什么都知道。

2.2 定义一个工厂接口：每个产品一个“生产车间”

接下来，我定义了一个专门负责“生产”支付客户端的接口：

java复制public interface PayFactory {
    PayClient create(Order order);
}

这个接口很简单，一个 create 方法，接收订单，返回一个可用的 PayClient。真正实现这个接口的类，每个支付渠道一个：

java复制public class AlipayFactory implements PayFactory {
    @Override
    public PayClient create(Order order) {
        // 支付宝自己的构造、参数校验、甚至代理设置都可以放这里
        return new AlipayClient(order.getAmount());
    }
}

public class WechatFactory implements PayFactory {
    @Override
    public PayClient create(Order order) {
        return new WechatClient(order.getAmount());
    }
}

public class CardFactory implements PayFactory {
    @Override
    public PayClient create(Order order) {
        return new CardClient(order.getAmount(), order.getCardNo());
    }
}

这一步做完，很多觉得不可思议的事就发生了：原来散落在业务代码里的 new 全部从业务方法里消失了。以后 AlipayClient 构造函数要是改参数，我只需要动 AlipayFactory，所有调用 PayFactory.create() 的地方都不受影响。支付宝的内部实现细节，被隔绝在它自己的工厂里。

2.3 用一个注册表替换掉“类型判断分支”

不过新问题马上来了：现在我们有 AlipayFactory、WechatFactory、CardFactory，可业务方法里还是得根据 order.getPayType() 来决定用哪个工厂。如果我只把原来的 new AlipayClient(...) 换成 new AlipayFactory().create(order)，那等于什么都没干，类型判断还在。

我的做法是引入一个注册表，让工厂和支付类型形成映射：

java复制public class PayFactorySelector {

    private final Map<Integer, PayFactory> payFactoryMap = new HashMap<>();

    public void register(Integer payType, PayFactory factory) {
        payFactoryMap.put(payType, factory);
    }

    public PayClient create(Order order) {
        PayFactory factory = payFactoryMap.get(order.getPayType());
        if (factory == null) {
            throw new UnsupportedOperationException("未知支付方式：" + order.getPayType());
        }
        return factory.create(order);
    }
}

然后业务代码变成：

java复制PayClient client = payFactorySelector.create(order);
client.pay();

原来到处出现的 if (type == 1) ... else if (type == 2)，在这里被 Map 的键值映射取代了。如果你想偷懒，想省掉注册表，直接在业务里写 if (type == 1) factory = new AlipayFactory()，那仍然是把渠道判断留在业务里，并没有真正解决问题。所以这个注册表是很重要的一环。

当时我为了让组装更灵活，注册动作放在系统启动阶段统一完成：

java复制PayFactorySelector selector = new PayFactorySelector();
selector.register(1, new AlipayFactory());
selector.register(2, new WechatFactory());
selector.register(3, new CardFactory());

这三种支付方式各自的创建逻辑，就被“装”进了不同的工厂对象里，跟业务代码彻底解耦。

2.4 重构后的客户端，再也不用“认识”具体支付实现类

重构完的 PayService.pay() 大概是这样的：

java复制public class PayService {

    private final PayFactorySelector payFactorySelector;

    public PayService(PayFactorySelector payFactorySelector) {
        this.payFactorySelector = payFactorySelector;
    }

    public void pay(Order order) {
        PayClient client = payFactorySelector.create(order);
        client.pay();
    }
}

这个方法现在只在乎一件事：从注册表拿到合适的 PayClient，然后调用支付。它不需要知道世界上有支付宝、微信、银行卡，也不需要知道它们的 type 是几。以后支付宝想改参数，支付宝自己的工厂去处理；以后新增云闪付，只需要在注册表里加一行；以后要删除某个渠道，只需要不注册它，或者把 Map 里对应项抹掉。

这就是工厂方法模式在我这个项目里体现出的真正价值：它把“创建哪一个对象”的决策权，从业务逻辑手里收走了，交给了独立的工厂对象。业务逻辑从此只依赖稳定的 PayFactory 抽象和 PayFactorySelector，那些易变的具体类，反而成了不会扩散到全系统的“隔间”。

3. 工厂方法模式的本质：不是模板，是“延迟到哪一步才知道类型”

3.1 先别急着抄代码，理解它到底在延迟什么

我见过很多同事一上来就背定义：定义一个创建对象的接口，让子类决定实例化哪一个产品类。背完之后照样不会用，原因就是没搞清楚“让子类决定”这几个字到底在解决什么问题。

直接 new 的时候，编译器和运行时不都得知道具体类型吗？我写 new AlipayClient(...)，那类型就在这一行写死了。后来用简单工厂，我们可以把类型判断集中到一个类里，但判断逻辑还是要在代码里出现。工厂方法的做法，是把判断本身“软化”了：

• 先把“工厂接口”定义出来，它声明一个 create 方法，不负责具体产品；
• 再为每一个具体产品各写一个工厂子类，比如 AlipayFactory、WechatFactory；
• 最后让外层代码依赖这个 PayFactory 接口，而不是依赖 AlipayFactory 还是 WechatFactory。

于是，一个对象到底是支付宝客户端还是微信客户端，就不是靠 if-else 在“使用产品”的时候当场判断，而是靠“实例化哪一个工厂子类”这件事来决定的。PayClient 的类型，从原来多个调用点各自决定，变成延迟到工厂子类那一层决定。

很多人第一次学到这里会问：那调用工厂子类的地方，不还是得判断吗？没错，但判断已经被大大收拢了。如果配合上一章那个注册表，调用方连判断都不需要做，Map 自己会根据 key 找到工厂。把类型判断压缩到最小，并让它收敛在单一位置，这正是工厂方法模式要的效果。

3.2 为什么说产品类和工厂类形成了一个“平行层级”

你仔细看会发现，代码里出现了两组并行的类：

• 产品：PayClient -> AlipayClient、WechatClient、CardClient
• 工厂：PayFactory -> AlipayFactory、WechatFactory、CardFactory

每个产品实现类都对应着一个工厂实现类。这种结构在模式书里叫“平行类层级”。平行层级的好处，是新增一个产品时，你可以在产品维度新增一个类，在工厂维度也新增一个类，两个类一一对应，互不干扰。

如果不用工厂方法，你的代码里只会有产品这一个层级在膨胀，而且是往老的逻辑结构里膨胀。用了工厂方法，膨胀变成了“新增一对类”，这给项目带来的收益非常明显：团队不同成员可以各自认领一个渠道的“产品类 + 工厂类”并行开发，互不产生代码冲突，也不会因为都在改同一个 PayService 而打起“我们什么时候合代码”的拉锯战。

3.3 “开闭原则”这次是真实地发生在哪里

开闭原则经常被说成一句空话，被人认为“那还不简单？别改就行”。可真正难的是：如何让系统对扩展开放时，不需要去改已经被验证过的旧代码。工厂方法模式是少数我能直观感受到开闭原则落地的模式之一。

在老的支付代码里，我要加一个渠道，必须去 PayService、退款模块、回调模块里，把旧的 if-else 改上一遍。这些旧代码可能在线上跑了一年半载，你说改就改，能不出事吗？用工厂方法后，我要加银联支付：

1. 新增 UnionPayClient 类，实现 PayClient 接口；
2. 新增 UnionPayFactory 类，实现 PayFactory 接口；
3. 在系统启动的注册处把 type=4 映射到 UnionPayFactory。

第三步严格说还要动一行注册代码，但如果项目用了 Spring 之类的容器，可以通过自动注入 PayFactory 实现类集合，连注册表代码都不需要改。哪怕不是容器环境，这第三行改动也属于“新增启动配置”，而不是修改旧的支付流程。老的 PayService、老的三个工厂、老的三个产品类，从头到尾都不用碰。新增功能不再等于修改旧代码，这就是“扩展开放、修改关闭”的真实落地。

当然，代价我也要讲清楚：工厂方法并没有消灭“每次加类型要写新类”的工作量，它只是把改动从“牵一发动全身”变成“局部新增”。如果加一个渠道你连新类都不想写，那是做不到的；但只要新类不会被塞进旧流程里，对线上老功能就是一种保护。

4. 实战验证：加第 N 个新功能，到底少了哪些改动？

4.1 用一次真实的“新增银联支付”来验收重构效果

重构完成后，我又一次接到了“加一种支付方式”的需求，这次是云闪付。我很刻意地记录了整个改动过程：

改动一：新建 UnionPayClient.java

java复制public class UnionPayClient implements PayClient {

    private final BigDecimal amount;

    public UnionPayClient(BigDecimal amount) {
        this.amount = amount;
    }

    @Override
    public void pay() {
        // 云闪付的支付逻辑
    }
}

改动二：新建 UnionPayFactory.java

java复制public class UnionPayFactory implements PayFactory {

    @Override
    public PayClient create(Order order) {
        // 云闪付可能要求不同的参数，可以在这里做兼容
        return new UnionPayClient(order.getAmount());
    }
}

改动三：在注册表里加一行：

java复制selector.register(4, new UnionPayFactory());

就这三件事。我不用再去支付模块加 else if，不需要去退款模块加 case，不需要去回调模块判断新的渠道名字符串。因为所有这些模块都只依赖 PayFactorySelector，而 PayFactorySelector 的 Map 里已经包含了新工厂。旧的 AlipayFactory、WechatFactory、CardFactory 一行没动，三个老产品类也一行没动，PayService 更是完全没打开。

整个过程带给我的体感差异，用一句话概括就是：原来加功能像在一栋老房子里凿墙布线，现在加功能像在柜子里多加一个抽屉。

4.2 对比一下重构前和重构后的改动范围

我列了一张表格，方便大家直观感受：

这张表最直观的差异是：老代码里要改的位置从“很多处”变成了“零处”，新功能需要新增的东西从“产品类 + 多处分支”变成了“产品类 + 工厂类 + 一行注册”。

4.3 千万别再搞出“工厂的工厂”

工厂方法模式用顺手之后，会有一种错觉：既然是“按照某种类型选择工厂”，那我应该再做一个工厂来创建工厂，否则选择逻辑还存在啊？

这个想法我说句实话，是过度设计的起点。我们引入注册表或者 Spring 的依赖注入容器，本质上是把“根据 key 找实现类”这件事交给框架或者 Map 去处理。这已经足够好，不需要再为 PayFactory 这个接口写一个专门的 PayFactoryFactory。

如果哪天需要加一种全新的支付渠道，我们新增一个 UnionPayFactory 不就行了吗？这个 UnionPayFactory 自己就在系统启动、组装阶段被注册进去，它不依赖另一个工厂。继续往上抽象，只会让代码套娃越套越深，后续新人进来读代码，看着一长串“工厂的工厂”头都要大。

5. 我从工厂方法上踩过的三个坑

5.1 坑一：把每个工厂都做成“万能总厂”

第一次照着模式重构时，我把 PayFactory 接口设计成了一个“万能总厂”，里面放了三个方法：

java复制public interface PayFactory {
    PayClient createByAlipay(Order order);
    PayClient createByWechat(Order order);
    PayClient createByCard(Order order);
}

每个实现类都要实现所有支付方式的创建方法，这不就是换了个马甲的简单工厂吗？更离谱的是，AlipayFactory 里被迫去实现自己不关心的微信创建逻辑。模式书里说的“工厂方法”，一个 Creator 子类应该只负责创建一个 ConcreteProduct 的实例。换成我们的业务场景，AlipayFactory 只管支付宝，WechatFactory 只管微信，这样才能保证每个工厂类都小而专注。搞成万能总厂，反而又变回了一个所有分支堆在一起的上帝类。

5.2 坑二：每个类都配一个工厂，结构爆炸

踩完第一个坑，我好像懂了，结果又走向另一个极端：我看项目里什么类都觉得值得建工厂，连订单创建这种根本不会变化的场景，也硬写了一个 OrderFactory。没过多久，项目里多了几十个工厂类，每个工厂都只被一个地方用到。

工厂方法模式的适用场景是：你有一个抽象产品，而且产品族经常有新增实现，或者产品创建过程较复杂。如果产品实现只有一种，或者未来一年内看不到新增的可能，真的没必要为 new 做一层隔离。管理几十个不创造价值的类，会让项目整体维护成本直线上升。后面我就学乖了：先用最直接的方式写代码，当“同类型的分支出现在两个以上文件”时，再考虑引入工厂方法。

5.3 坑三：为了“以后可能扩展”提前引入工厂

“现在只有一个支付宝，但以后肯定会加很多支付方式，赶紧用工厂方法吧。”我承认，这句话也曾经是我写代码时给自己找的理由。可现实是，那个“以后”可能永远不会来。为了一个幻想出来的未来，让现有代码多出一层抽象，后来的维护者读代码时就要多绕一个弯。

我现在更相信“让模式出现在它被需要的时刻”。当你真的被“加功能就要改底朝天”困扰时，当你在项目里搜索到三四处相互重复的“根据类型创建对象”时，工厂方法就是那个能够救你出水火的工具。它不是装饰品，不该被提前挂在脖子上当护身符。

回到最初的问题：为什么加个新功能，要把旧代码改个底朝天？根本原因是新增类型的传播路径没有封闭。工厂方法模式把产品的创建过程拆到单独的工厂子类里，相当于给每个新增类型修了一条独立的管道，新类型的接入和旧类型彻底隔离，旧代码自然就不必被反复折腾了。如果你现在正被“加一个功能，改一整片旧代码”折磨，可以先搜一搜项目里到底藏着多少个重复的类型判断分支，再决定要不要把工厂方法请进来。搜索的结果会让你很清醒。