拒绝满屏 new：用 PHP 工厂模式给业务代码“松绑”

写 PHP 的人大概都经历过这种尴尬：业务跑起来后，控制器里堆满了各式各样的 new PaymentWechat() 和 new LogisticsSF()。每次接入新渠道，就得去核心文件里插空修改，改完还得拉着测试重新走一遍流程。耦合度像一团理不清的毛线球，牵一发而动全身。这时候就该请出工厂模式了，它不是教科书里的炫技概念，而是专门用来收拾这些杂乱实例化的“收纳师”。

搭建工厂的核心逻辑很直白，先把行为契约抽离出来，再把实例化动作集中到一处。新建一个 Interface，把所有同类产品必须对外暴露的方法钉死，比如统一的处理入口或状态校验方法。具体类只管实现这个接口，绝不越界添加无关属性。接口一旦定型，各个细分类就可以独立演进，不同支付通道调各自的 SDK，物流接口拼各自的签名算法，彼此隔离，互不牵扯。

契约和骨架都就位，工厂类的实现就成了收尾工作。建议采用静态方法作为入口，把路由分发逻辑牢牢锁死在内部。严格前置参数校验，拿不到合法标识直接拦截，绝不往里输送脏数据。使用 match 表达式替代冗长的条件判断，键名绑定业务常量，返回值直接吐出新实例。外部调用端从此只需维护一行 $handler = OrderFactory::build($channel)，底层换了十几种实现策略，上层代码连注释都不用动。

落地到真实项目，很多人容易把工厂玩变形。动不动就把工厂塞进单例，或者强行挂载到容器里做全局缓存，反而拖慢了请求速度并增加了排查难度。轻量级的对象创建，普通静态方法效率最高；若工厂内部确实需要复用数据库连接或缓存驱动，直接在构造函数里按需注入，保持它的职责单一。更要警惕过度设计，同类对象若长期稳定只有两三种且生命周期极短，硬编码反而比绕一圈工厂更直观。工厂模式的真正价值在于兜底高频变更，而不是替尚未发生的业务提前搭台。

解耦从来不是一次性的重构工程，而是日常敲代码时的肌肉记忆。把创建对象的权力移交出去，相当于给系统预留了热替换空间。后续需求扩容时，不用再全局搜索替换实例化位置，只需要在工厂的路由分支里追加一条映射规则。写架构就像整理工作台，台面清空了，顺手捞取工具才不费劲。下次再面对满屏的对象初始化，不妨停下鼠标思考两秒，把制造权交出去，让工厂替你扛下复杂度。