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

最新推荐文章于 2024-10-11 22:55:11 发布

Solomon_肖哥弹架构

最新推荐文章于 2024-10-11 22:55:11 发布

阅读量981

点赞数 10

分类专栏： Java 架构设计 spring boot 文章标签：依赖倒置原则设计要素设计原则

本文链接：https://blog.csdn.net/alises1314/article/details/140331667

版权

Java 同时被 3 个专栏收录

222 篇文章 1 订阅

订阅专栏

spring boot

160 篇文章 0 订阅

订阅专栏

架构设计

20 篇文章 0 订阅

订阅专栏

在这里插入图片描述

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

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

欢迎点赞，点赞，点赞。

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

历史热点文章

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

在这里插入图片描述

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 的实现负责，符合单一职责原则。