依赖倒置原则：高层模块如何依赖抽象接口而非具体实现

如何通过依赖倒置原则实现高层模块依赖抽象

要让高层模块依赖抽象接口而不是具体实现，关键在于将“谁创建、谁调用、谁绑定”这三个环节从硬编码中抽离，转而通过契约（接口或抽象类）来组织关系。这听起来有些抽象，但实际操作起来是一套非常清晰的组合方法。

长期稳定更新的攒劲资源： >>>点此立即查看<<<

定义清晰的抽象接口

接口的设计核心在于提炼出稳定不变的行为契约。例如，在设计订单服务时，不应直接开始编写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”)即可轻松为测试环境配置模拟实现。

通过这种方式，高层模块的代码完全无需修改，仅通过外部配置即可灵活切换数据源、日志组件、支付网关等具体实现。这不仅提升了代码的可测试性，也使系统在面对变化时具备了真正的弹性。