依赖倒置原则：支付网关设计应用案例-CSDN博客

依赖倒置原则：支付网关设计应用案例_springboot

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

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

欢迎点赞，点赞，点赞。

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

历史热点文章

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

依赖倒置原则：支付网关设计应用案例_依赖倒置原则_02

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 */) {
        // 从数据库生成报告的逻辑
    }
}

问题分析：

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

解决的问题：

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