面试官考PHP面向对象重构重在识别坏味道并用OOP理清逻辑链路，即识别问题→理解职责→拆分抽象→建立关系；典型问题包括职责过载、硬编码依赖、条件爆炸、逻辑重复，应通过接口抽象、策略模式、值对象、领域事件等解耦优化。
为什么面试官爱问 PHP 面向对象重构题
不是考你背了多少设计模式，而是看你能不能从“能跑就行”的代码里，嗅出坏味道，再用 OOP 的工具把它理清楚。重点在 识别问题 → 理解职责 → 拆分抽象 → 建立关系 这条链路上是否自然、合理。
常见待重构代码片段及改法
面试中常给一段过程式或紧耦合的 PHP 代码，比如订单处理逻辑混着数据库操作、支付校验、日志记录、通知发送全塞在一个方法里。典型问题包括：
- 一个类/方法承担太多职责（违反单一职责）
- 硬编码依赖（如 new MySQLi()、直接调用 Mailer::send()）
- 条件分支爆炸（一堆 if-else 判支付方式、订单状态）
- 重复逻辑散落各处（如金额格式化、参数校验）
重构建议：
- 把“做什么”和“怎么做”分开：抽离 OrderService、PaymentGateway、NotificationSender 等接口，用依赖注入传递具体实现
- 用策略模式替代长 if-else：比如不同支付方式（Alipay、WechatPay）各自实现 PaymentStrategy 接口
- 把校验、格式化等通用能力封装成 Value Object（如 Money、OrderId）或独立 Validator 类
- 引入领域事件（如 OrderPaidEvent），让通知、积分、库存扣减等后续动作解耦响应，而非强调执行顺序
面试时怎么讲清楚你的重构思路
别一上来就贴代码。先说你看到了什么问题，再解释为什么这么改比原来好。例如：
立即学习“PHP免费学习笔记（深入）”；
- “原代码里 OrderController 直接 new 了 PDO，导致没法单元测试，也锁死了数据库类型——我把它改成依赖 DatabaseInterface，测试时可注入 MockPDO”
- “优惠计算逻辑被复制在 createOrder 和 applyCoupon 两个地方，我提取成 DiscountCalculator 类，保证同一规则只定义一次”
- “订单状态流转靠字符串判断（'pending'/'paid'），容易拼错且难扩展——我改用 State 模式，每个状态是独立类，流转规则收口在 Order 类内部”
加分细节：别只写对，要写出“可维护感”
面试官会留意你是否考虑真实协作场景：
- 接口命名是否表达意图（比如叫 CanBeShipped 而不只是 IsShippable）
- 是否预留扩展点（如构造函数参数用接口而非具体类，方法参数用 array|string 而非硬写 string）
- 异常处理是否分层（领域异常抛 DomainException，基础设施异常转为 InfrastructureException）
- 是否加了类型声明（PHP 7.4+ 支持 property type、return type）和 PHPDoc 补充契约
不复杂但容易忽略。
