image.png

依赖倒置原则（Dependency Inversion Principle, DIP）是SOLID原则的一部分，它提倡在设计时依赖于抽象（接口或抽象类），而不是具体的实现。这有助于降低模块间的耦合度，提高系统的可扩展性和可维护性。

肖哥弹架构 跟大家“弹弹” 代码设计技巧，需要代码关注

欢迎 点赞，点赞，点赞。

关注公号Solomon肖哥弹架构获取更多精彩内容

历史热点文章

• 数据访问对象模式（Data Access Object Pattern）：电商平台商品管理实战案例分析
• Holder模式（Holder Pattern）：公司员工权限管理系统实战案例分析
• 一个项目代码讲清楚DO/PO/BO/AO/E/DTO/DAO/ POJO/VO

2. 依赖倒置原则设计图：

image.png

3. 依赖倒置原则解决什么：

依赖倒置原则解决了在支付网关设计中，业务逻辑层与具体支付实现之间的紧密耦合问题。

4. 依赖倒置原则特点：

• 抽象化依赖：高层模块依赖于抽象接口，而不是具体的实现类。
• 灵活性增强：可以灵活地替换或增加新的支付处理器，而不影响业务逻辑层。

5. 依赖倒置原则缺点：

• 可能增加设计复杂性：需要更多的接口定义和实现类。
• 性能考虑：间接层可能对性能有一定影响，尤其是在高性能要求的场景下。

6. 依赖倒置原则使用场景：

• 当系统需要支持多种支付方式，并且预期会引入更多支付方式或修改现有支付逻辑时。
• 在ERP系统中，当需要从多个数据源生成报告，或预期报告生成方式将随时间变化时。

7. 依赖倒置原则案例

7.1 支付网关案例

重构前：

    public class PaymentGateway {
        public PaymentResponse processPayment(PaymentDetails details) {
            // 直接使用具体的支付处理器
            return new CreditCardProcessor().charge(details);
        }
    }

    class CreditCardProcessor {
        public PaymentResponse charge(PaymentDetails details) {
            // 处理信用卡支付逻辑
            return new PaymentResponse();
        }
    }

重构后：

    interface IPaymentProcessor {
        PaymentResponse charge(PaymentDetails details);
    }

    class CreditCardProcessor implements IPaymentProcessor {
        public PaymentResponse charge(PaymentDetails details) {
            // 处理信用卡支付逻辑
            return new PaymentResponse();
        }
    }

    class PayPalProcessor implements IPaymentProcessor {
        public PaymentResponse charge(PaymentDetails details) {
            // 处理PayPal支付逻辑
            return new PaymentResponse();
        }
    }

    class PaymentGateway {
        private IPaymentProcessor paymentProcessor;

        public PaymentGateway(IPaymentProcessor paymentProcessor) {
            this.paymentProcessor = paymentProcessor;
        }

        public PaymentResponse processPayment(PaymentDetails details) {
            // 依赖于抽象的支付处理器接口
            return paymentProcessor.charge(details);
        }
    }

    // 使用PaymentGateway
    PaymentGateway gateway = new PaymentGateway(new CreditCardProcessor());
    PaymentResponse response = gateway.processPayment(new PaymentDetails());

7.1 ERP 案例

重构前：

public class FinancialModule {
    public void generateReports() {
        // 直接依赖于具体的数据库报告生成服务
        DatabaseReportingService service = new DatabaseReportingService();
        service.generate(...);
    }
}

class DatabaseReportingService {
    public void generate(/* parameters */) {
        // 从数据库生成报告的逻辑
    }
}

问题分析：

1. 紧耦合: FinancialModule 直接依赖于 DatabaseReportingService 的具体实现，耦合度高，导致系统灵活性差。
2. 扩展性差: 当需要添加新的报告生成方式（例如基于文件的报告）时，可能需要修改 FinancialModule 的代码，这违背了开闭原则。
3. 维护困难: 如果 DatabaseReportingService 的接口或实现发生变化，可能会影响到 FinancialModule，增加了维护成本。
4. 测试复杂性: 直接依赖具体实现使得单元测试 FinancialModule 变得复杂，可能需要大量模拟（mocking）具体类。
5. 代码重复: 如果系统中其他模块也需要生成报告，可能会复制 FinancialModule 中的代码，导致代码重复。

重构后：

interface ReportingService {
    void generate(ReportRequest request);
}

class DatabaseReportingService implements ReportingService {
    public void generate(ReportRequest request) {
        // 从数据库生成报告的逻辑
    }
}

class FileBasedReportingService implements ReportingService {
    public void generate(ReportRequest request) {
        // 从文件生成报告的逻辑
    }
}

class FinancialModule {
    private ReportingService reportingService;

    public FinancialModule(ReportingService reportingService) {
        this.reportingService = reportingService;
    }

    public void generateReports(ReportRequest request) {
        // 使用抽象的报告服务生成报告
        reportingService.generate(request);
    }
}

// 使用FinancialModule
FinancialModule financialModule = new FinancialModule(new DatabaseReportingService());
financialModule.generateReports(new ReportRequest());

解决的问题：

1. 解耦合: FinancialModule 现在依赖于 ReportingService 接口，而不是任何具体实现，降低了耦合度。
2. 扩展性增强: 新的报告生成方式（如 FileBasedReportingService）可以通过实现 ReportingService 接口轻松添加，无需修改 FinancialModule。
3. 维护简化: 由于 FinancialModule 不依赖于具体实现，因此维护和升级报告生成服务时对 FinancialModule 的影响较小。
4. 测试简化: 可以轻松地为 FinancialModule 编写单元测试，只需模拟 ReportingService 接口，而不是具体实现。
5. 代码复用: 其他需要报告生成功能的模块可以重用 FinancialModule，通过注入不同的 ReportingService 实现来满足特定需求。
6. 依赖注入: 通过构造函数或设置器注入 ReportingService 的实现，提高了 FinancialModule 的灵活性和可配置性。
7. 单一职责: FinancialModule 专注于其业务逻辑，而报告生成的具体细节由 ReportingService 的实现负责，符合单一职责原则。

8. 参考开源框架：

在Apache Camel等集成框架中，通过使用自定义组件和处理器，遵循依赖倒置原则，实现灵活的消息路由和处理。

9. 总结：

依赖倒置原则在支付网关设计中的应用，通过引入抽象层，有效地解耦了业务逻辑与具体支付实现。这不仅提高了系统的灵活性和可扩展性，也使得新增或修改支付方式变得更加简单。遵循依赖倒置原则有助于构建更加健壮、易于维护的系统，尤其是在需要支持多种支付方式的电子商务平台中。

历史热点文章

• 享元模式（Flyweight Pattern）：网页游戏中的角色对象管理实战案例分析
• 观察者模式（Observer Pattern）：股票交易系统实战案例分析
• 策略模式（Strategy Pattern）：电商平台的优惠券系统实战案例分析
• 模板方法模式（Template Method Pattern）:视频播放应用实战案例分析
• 命令模式（Command Pattern）:网络爬虫任务队列实战案例分析
• 迭代器模式（Iterator Pattern）：电商平台商品分类浏览实战案例分析
• 中介者模式（Mediator Pattern）:即时通讯软件实战案例分析
• 备忘录模式（Memento Pattern）:游戏存档系统实战案例分析
• 状态模式（State Pattern）:电商平台订单状态管理实战案例分析
• 责任链模式（Chain of Responsibility Pattern）：电商平台的订单审批流程实战案例分析
• 访问者模式（Visitor Pattern）:电商平台商品访问统计实战案例分析
• 工厂方法模式（Factory Method Pattern）: 电商多种支付实战案例分析
• 抽象工厂模式（Abstract Factory Pattern）：多风格桌面应用实战案例分析
• 建造者模式（Builder Pattern）： 在线订单系统实战案例分析
• 原型模式（Prototype Pattern）: 云服务环境配置实战案例分析
• 适配器模式（Adapter Pattern）:第三方支付集成实战案例分析
• 装饰器模式（Decorator Pattern）:电商平台商品价格策略实战案例分析
• 单例模式（Singleton Pattern）：购物车实战案例分析