痛点分析：紧耦合带来的扩展与测试困境
在早期的业务代码中，高层模块往往直接实例化低层模块。以电商订单服务为例，OrderService 内部直接使用 new 关键字创建 WeChatPayClient 和 SmsNotifier。这种写法导致业务逻辑与具体技术实现深度绑定：一旦需要接入支付宝或邮件通知，就必须修改订单核心代码，这不仅违反开闭原则，还使得单元测试变得极其脆弱——每次测试都需要真实调用外部网络接口，导致测试缓慢且依赖环境。此外，若将所有通知能力强行塞入一个巨大的 INotification 接口，新增的客户端将被迫实现大量无关方法，产生大量空实现或引发运行时异常。
依赖倒置：通过抽象接口实现解耦
解决上述问题的第一步是实施依赖倒置原则（DIP）。我们需要识别业务类中所有直接实例化的基础设施组件，如数据库访问类或第三方 SDK。以支付功能为例，将 WeChatPayClient 的具体调用提取为 IPaymentGateway 接口，仅保留 PayAsync 和 RefundAsync 等稳定契约。随后，在 OrderService 中移除 new 关键字，改为通过构造函数接收 IPaymentGateway 实例。借助依赖注入容器，在应用启动时完成具体实现与抽象的绑定映射。此过程将业务规则与底层技术实现彻底剥离，业务层仅面向接口编程。当需要切换支付渠道时，只需注册新的实现类并更新配置，无需触碰订单核心逻辑，真正实现关注点分离与运行时可替换。
接口隔离：按客户端需求拆分接口
判断接口是否臃肿的核心标准是：是否存在实现类被迫提供空方法，或调用方需进行类型转换才能使用特定功能。重构时应按客户端实际调用场景拆分。例如原 IUserService 包含 Login、ExportData、SendMarketingEmail，但认证模块仅需登录，报表模块只需导出，营销模块只需发邮件。将其拆分为 IAuthenticator、IReportExporter、IMarketingNotifier 后，各模块仅依赖自身所需接口，依赖图从网状变为星型。DIP 与 ISP 在此协同发力：DIP 确保业务依赖抽象而非具体类，ISP 确保抽象粒度与业务边界对齐。验证时可通过静态分析工具检查调用链，确认无冗余引用，且新增客户端无需修改现有接口契约，实现真正的按需依赖。
验证与避坑：测试策略与常见误区
重构后的解耦效果需通过自动化测试严格验证。使用 Mock 框架模拟 IPaymentGateway，在单元测试中注入伪造对象，断言订单状态流转逻辑，彻底隔离网络与数据库依赖。替换实现时，只需在集成测试中注入真实 SDK，验证端到端流程。常见误区包括：过度抽象（为每个实体类创建接口导致维护成本飙升）、接口碎片化（拆分过细使依赖管理混乱）、为 SOLID 而 SOLID（忽视 YAGNI 原则引入不必要的间接层）以及错误划分边界（按技术分层而非业务能力拆分）。判断标准应聚焦于变更影响面：若新增需求仅修改一处实现且不影响其他模块，说明抽象合理；若接口频繁因不同客户端需求而变更，则需重新审视职责划分。
