要实现高层模块依赖抽象接口而非具体实现，关键在于将“创建、调用、绑定”三个环节从硬编码中解耦，转而通过稳定的契约（接口或抽象类）来定义模块间的协作关系。这不仅是设计原则，更是一套可落地的工程实践方法。
定义清晰稳定的抽象接口
接口的核心价值在于定义稳定不变的行为契约，而非形式主义。以订单服务为例，不应直接编写OrderServiceImpl，而应首先设计OrderService接口，明确声明create()、cancel()等业务语义清晰的方法。这样，无论是基于数据库、内存缓存还是用于单元测试的模拟实现，都必须遵循同一套契约，从而将变化的部分与稳定的部分彻底分离。
高层模块仅依赖接口类型
在编写业务逻辑类（如PaymentProcessor）时，应严格遵循一项编码纪律：所有成员变量、方法参数及返回值类型均声明为接口类型。这意味着必须杜绝在代码中直接new XxxServiceImpl()或引用具体类名的做法。
- ✅ 正确方式：
private final OrderService orderService; - ❌ 错误方式：
private final OrderServiceImpl orderService; - ✅ 推荐方法签名：
public void process(OrderService service) - ❌ 不推荐方法签名：
public void process(OrderServiceImpl service)
这一步从代码声明层面确立了依赖关系的规范，从根本上避免了与具体实现的直接耦合。
实现类由外部注入，实现解耦
具体实现类不应由高层模块主动实例化，而应通过外部机制注入。高层模块仅声明“我需要一个具备订单处理能力的服务”，至于该服务的具体实现类型及其来源，则无需关心。常见的依赖注入方式包括：
- 构造函数注入：在创建高层模块对象时，将实现类实例通过构造器参数传入。这是最推荐的方式，能确保依赖在对象生命周期开始时即完备且不可变。
- Setter方法注入：提供
public setXxx(Interface impl)方法，允许容器或测试代码在对象创建后动态设置依赖。灵活性更高，但可能引入状态不确定性。 - 工厂模式或服务定位器：相对重量级的方案，通常在遗留系统改造或向依赖注入架构过渡时作为临时策略使用。
通过注入机制，高层模块完全无需感知底层使用的是MySQL、Redis还是其他数据源，只要传入的对象符合接口契约，即可正常工作。
运行时绑定交由框架或配置管理
最终注入哪个具体实现，这一决策权应交给应用框架或外部配置。例如在Spring Boot中，只需在实现类上标注@Service注解；若需指定默认实现，可使用@Primary；根据环境切换实现则可借助@Profile(“test”)注解为测试环境配置模拟服务。
如此，高层模块的业务代码无需任何修改，仅通过外部配置即可灵活切换数据源、日志组件、支付网关等具体实现。这不仅大幅提升了代码的可测试性，也使系统在应对业务变化与技术演进时，具备了真正的弹性与可维护性。
