工厂模式详解：从原理到实战，轻松掌握设计模式核心技巧

欢迎来到设计模式深度解析系列，在这里您将看到关于工厂模式从底层原理到项目实战的完整拆解。以下是本文精彩内容：如何用工厂模式解决对象创建的复杂性、三种工厂变体的适用场景对比，以及一个真实电商系统中的代码示范。

为什么你的代码总在new对象时卡壳？

直接new对象就像在流水线上徒手组装零件——当产品类型增多时，你会发现到处都是重复的零件拼接代码。上周有个做支付系统的工程师告诉我，他们每次接入新支付渠道就要修改20多处new Payment()的代码。这时候工厂模式的价值就凸显了：它把对象的创建过程封装在专属车间里，外界只需要知道车间门牌号。

简单工厂：菜鸟的第一个设计模式

先看这个最基础的实现版本。假设你在开发游戏道具系统，没有工厂时代码可能是这样的：

if(type == "sword") {
    weapon = new Sword();
} else if(type == "shield") {
    weapon = new Shield();
}

用简单工厂改造后，所有创建逻辑收拢到一个类中。但它的局限也很明显——新增武器类型必须修改工厂类的if-else块，这违反了开闭原则。不过对于中小型项目，这种写法反而比过度设计更实用。

工厂方法模式：让子类决定生产什么

当你的系统需要支持多国电商物流时，基础工厂就力不从心了。美国订单需要Fedex，日本订单需要Yamato运输——这时候应该用工厂方法。每个国家物流子类继承自抽象物流工厂，自行实现createShipping()方法。这种模式最妙的是：调用方代码完全不用关心具体物流类型，就像你不知道快递小哥怎么找到你家门的。

抽象工厂：解决产品族创建难题

跨平台UI库是最典型的应用场景。Mac按钮和Windows按钮属于不同产品族，但都要保证风格统一。抽象工厂定义createButton()、createMenu()等接口，由具体工厂实现整套控件创建。有个容易踩的坑：不要为了用模式而用模式，当你的系统确实存在多个关联产品族时再考虑它。

实战：电商优惠券系统的工厂改造

来看真实案例。某平台最初用简单工厂生成折扣券、满减券，后来新增裂变券时发现要修改核心逻辑。我们将其重构为工厂方法模式：

public interface CouponFactory {
    Coupon createCoupon();
}

public class DiscountFactory implements CouponFactory {
    public Coupon createCoupon() {
        return new DiscountCoupon();
    }
}

现在新增券类型只需扩展新工厂类，原有代码纹丝不动。更重要的是——券的创建逻辑和业务逻辑彻底解耦，单元测试也变得更容易。

那些教科书不会告诉你的细节

1. 工厂类通常设计为单例，因为没必要重复创建工厂实例
2. 在Spring框架中，BeanFactory本身就是工厂模式的顶级实现
3. 过度使用工厂模式会导致类爆炸，10个以下产品类型用简单工厂更合适
4. 结合反射机制可以实现动态工厂，但要注意性能损耗

下次当你在代码中看到大量new操作符时，不妨想想是否该召唤工厂模式了。记住设计模式的本质：不是炫技，而是用合理的设计让代码更适应变化。

免责声明：以上内容仅为信息分享与交流，希望对您有所帮助