类继承与工厂模式搭配：让代码更灵活的实战技巧

类继承与工厂模式搭配：让代码更灵活的实战技巧

在开发一个电商后台系统时，经常会遇到不同类型的订单处理逻辑——普通订单、团购订单、秒杀订单。它们的创建流程相似，但具体行为又有差异。这时候如果只用类继承，代码容易变得臃肿；如果只用工厂模式，又缺乏复用性。把两者搭在一起，反而能发挥出更好的效果。

比如先定义一个基础订单类，封装共用的方法：

class Order {
    process() {
        this.validate();
        this.create();
        this.notify();
    }

    validate() {
        console.log("验证订单数据");
    }

    create() {
        throw new Error("子类必须实现 create 方法");
    }

    notify() {
        console.log("发送订单通知");
    }
}

接着让不同订单类型继承它，各自实现特有的 create 行为：

class RegularOrder extends Order {
    create() {
        console.log("生成普通订单");
    }
}

class GroupBuyOrder extends Order {
    create() {
        console.log("生成团购订单，检查成团人数");
    }
}

class FlashSaleOrder extends Order {
    create() {
        console.log("生成秒杀订单，校验库存和限抢规则");
    }
}

这时候如果直接在业务代码里 new 不同的类，调用方就得知道每种类型的细节，耦合度高。引入工厂模式来解耦：

class OrderFactory {
    static create(type) {
        switch (type) {
            case "regular":
                return new RegularOrder();
            case "group":
                return new GroupBuyOrder();
            case "flash":
                return new FlashSaleOrder();
            default:
                throw new Error("不支持的订单类型");
        }
    }
}

现在创建订单只需要一句话：

const order = OrderFactory.create("group");
order.process();

新增一种订单类型时，只需新增一个子类并修改工厂的判断逻辑，原有代码不需要大动。这种组合方式既利用了类继承带来的代码复用，又通过工厂模式隔离了对象创建的复杂性。

实际项目中，这种搭配在表单验证、支付渠道、消息推送等场景都很常见。比如用户提交不同的表单，共用校验流程，但具体规则由子类实现，再通过工厂按类型生成对应的处理器。代码结构清晰，扩展也方便。

关键点在于，父类负责稳定流程，子类负责变化逻辑，工厂负责选择具体实现。三者各司其职，比单独使用某一种设计模式更贴近真实开发需求。