提炼接口是围绕职责边界抽象出紧密相关的行为契约，用于支撑依赖倒置、降低耦合、便于多态扩展与测试替换；适用场景包括多类重复实现同组方法、类承担过多角色、测试需模拟部分方法、频繁类型判断等；提炼需经识别契约动词、剥离实现细节、重定向依赖三步；须避免过度拆分、命名脱离业务、忽略演化成本；接口与抽象类、组合协同：接口定义“能做什么”，抽象类解决“怎么做”，组合支持多能力复用。
提炼接口（Extract Interface）是面向对象重构中一项关键操作，它不是简单地把已有类的方法“抄”出来贴成接口，而是围绕职责边界做一次清醒的抽象——把一组紧密相关、可被不同实现共同承诺的行为契约，明确抽离为独立接口。这样做，能直接支撑依赖倒置、降低耦合，并为后续多态扩展与测试替換打下基础。
什么时候该提炼接口
当出现以下信号时，就是提炼接口的合理时机：
- 多个不相关的类实现了相同的一组方法（比如save()、validate()、toDto()），但它们没有继承关系，也不该强行拉进一个父类
- 某个类承担了太多角色，外部模块总在用它完成不同语义的操作（例如既当数据载体、又做业务校验、还负责序列化），导致调用方依赖了大量无关行为
- 单元测试中频繁需要模拟整个类，但只关心其中几个方法——说明这些方法构成了一组可独立契约
- 你发现某段逻辑总在判断if ($obj instanceof Exportable && $obj instanceof Validatable)——这其实是接口职责混杂的警示灯
怎么提炼：三步聚焦法
避免“为接口而接口”，提炼要服务于真实协作场景：
- 识别契约动词：从现有类中圈出被同一类调用方反复使用的若干方法，比如canPublish()、publish()、getPublishError()，它们共同表达“发布能力”这一语义，就可提炼为Publishable接口
- 剥离实现细节：接口里只保留签名和文档注释，不带任何逻辑、属性、构造函数或静态方法；若某方法依赖私有状态，先确认它是否真属于该契约——否则应留在具体类中
- 重定向依赖：将原调用方的类型提示、参数类型、变量声明，从具体类名改为新接口名；例如把function handle(User $user)改为function handle(Authenticatable $user)
常见误区与应对
提炼接口容易滑向形式主义，需警惕几个典型偏差：
- 过度拆分：把getName()和getEmail()硬拆成两个接口。应看调用上下文——如果总有模块同时用这两个方法，它们就属于同一契约
- 命名脱离业务：起名IDataProvider或IEntity，等于没抽象。优先用动词+able结构（如Searchable、Retryable）或领域术语（如Payable、Shippable）
- 忽略演化成本：接口一旦发布给外部使用，修改就牵一发而动全身。初期可加@internal注解，等稳定后再开放；新增方法尽量用默认实现（PHP 8.0+）或版本化接口（如PublishableV2）
和抽象类、组合的关系
提炼接口不是替代其他机制，而是协同工作：
- 接口定义“能做什么”，抽象类解决“怎么做”的共性——比如多个Exportable实现共享formatCsv()逻辑，就可在抽象基类里提供默认实现
- 当一个类需要多个能力（如既是Exportable又是Archivable），用接口组合天然支持，比单继承灵活得多
- 若某能力涉及状态管理（如缓存、连接池），更适合封装为独立服务类，再通过依赖注入交由主类组合使用，而非塞进接口
