小谈设计模式(6)—依赖倒转原则

简介: 小谈设计模式(6)—依赖倒转原则

专栏介绍

专栏地址

link

专栏介绍

主要对目前市面上常见的23种设计模式进行逐一分析和总结,希望有兴趣的小伙伴们可以看一下,会持续更新的。希望各位可以监督我,我们一起学习进步,加油,各位。

依赖倒转原则

依赖倒转原则(Dependency Inversion Principle,DIP)是面向对象设计中的一个重要原则,它指导着如何构建松耦合、可扩展和可维护的软件系统。该原则由罗伯特·C·马丁(Robert C. Martin)提出。

核心思想

通过抽象来解耦高层模块和低层模块之间的依赖关系。

关键点分析

a

高层模块不应该依赖于低层模块的具体实现,而是依赖于抽象接口。这意味着高层模块应该定义一个抽象接口,而低层模块实现该接口。通过依赖于抽象接口,高层模块可以独立于具体实现进行编程。

b

抽象接口应该由高层模块定义,而不是由低层模块定义。这样可以确保高层模块对于依赖的控制,而不会受到低层模块的限制。高层模块可以根据自己的需求定义接口的方法和属性,而不需要依赖于低层模块的具体实现细节。

c

依赖注入是实现依赖倒转原则的重要手段。通过依赖注入,高层模块可以将具体实现类的对象传递给抽象接口。依赖注入可以通过构造函数、方法参数或者属性注入的方式实现。这样可以实现解耦,高层模块不需要关心具体实现类的创建和管理。

优缺点分析

优点

降低模块间的耦合度

通过依赖倒转原则,高层模块不依赖于低层模块的具体实现,而是依赖于抽象接口。这样可以使得模块之间的耦合度降低,提高代码的灵活性和可维护性。

提高代码的可扩展性

由于高层模块不依赖于低层模块的具体实现,当需要新增或修改低层模块时,只需要修改具体实现类而不需要修改高层模块的代码。这样可以提高代码的可扩展性,减少对现有代码的影响。

便于进行单元测试

由于高层模块依赖于抽象接口,可以通过使用模拟对象来进行单元测试,而不需要依赖于具体实现类。这样可以更容易地进行测试,提高代码的质量。

缺点

增加代码的复杂性

依赖倒转原则需要引入抽象接口和依赖注入等机制,这会增加代码的复杂性和理解难度。特别是在项目规模较小或简单场景下,引入这些机制可能会显得过于繁琐。

需要额外的设计和开发工作

在应用依赖倒转原则时,需要进行额外的设计和开发工作,包括定义抽象接口、实现具体实现类、进行依赖注入等。这会增加开发成本和工作量。


综上所述,依赖倒转原则在一定程度上可以提高代码的灵活性、可维护性和可扩展性,但也需要权衡其引入的复杂性和开发成本。在设计和开发过程中,需要根据具体的场景和需求来决定是否采用依赖倒转原则。

Java代码实现

// 定义抽象接口
public interface MessageSender {
    void sendMessage(String message);
}

// 具体实现类1
public class EmailSender implements MessageSender {
    @Override
    public void sendMessage(String message) {
        System.out.println("Sending email: " + message);
    }
}

// 具体实现类2
public class SmsSender implements MessageSender {
    @Override
    public void sendMessage(String message) {
        System.out.println("Sending SMS: " + message);
    }
}

// 高层模块,依赖于抽象接口
public class NotificationService {
    private MessageSender messageSender;

    // 通过构造函数进行依赖注入
    public NotificationService(MessageSender messageSender) {
        this.messageSender = messageSender;
    }

    public void sendNotification(String message) {
        // 调用抽象接口的方法
        messageSender.sendMessage(message);
    }
}

// 测试代码
public class Main {
    public static void main(String[] args) {
        // 创建具体实现类的对象
        MessageSender emailSender = new EmailSender();
        MessageSender smsSender = new SmsSender();

        // 创建高层模块的对象,并传入具体实现类的对象
        NotificationService emailNotificationService = new NotificationService(emailSender);
        NotificationService smsNotificationService = new NotificationService(smsSender);

        // 调用高层模块的方法
        emailNotificationService.sendNotification("Hello, this is an email notification.");
        smsNotificationService.sendNotification("Hello, this is an SMS notification.");
    }
}

示例分析

在抽象接口MessageSender定义了发送消息的方法。具体实现类EmailSender和SmsSender分别实现了该接口,并提供了发送邮件和发送短信的具体实现。高层模块NotificationService依赖于抽象接口MessageSender,通过构造函数进行依赖注入,从而实现了依赖倒转原则。


总结

依赖倒置原则强调了面向抽象编程的重要性,通过抽象接口和依赖注入等技术,可以降低模块之间的耦合度,提高代码的灵活性和可维护性。

相关文章
|
7月前
|
设计模式 Java 数据库
小谈设计模式(2)—简单工厂模式
小谈设计模式(2)—简单工厂模式
|
7月前
|
设计模式 算法 Java
小谈设计模式(3)—策略模式
小谈设计模式(3)—策略模式
|
7月前
|
设计模式 Java
小谈设计模式(26)—中介者模式
小谈设计模式(26)—中介者模式
|
7月前
|
设计模式 算法 Java
小谈设计模式(30)—Java设计模式总结
小谈设计模式(30)—Java设计模式总结
|
7月前
|
设计模式 存储 Java
小谈设计模式(28)—解释器模式
小谈设计模式(28)—解释器模式
|
7月前
|
设计模式 存储 Java
小谈设计模式(27)—享元模式
小谈设计模式(27)—享元模式
|
7月前
|
设计模式 Java
小谈设计模式(25)—职责链模式
小谈设计模式(25)—职责链模式
|
7月前
|
设计模式 算法 Java
小谈设计模式(29)—访问者模式
小谈设计模式(29)—访问者模式
|
7月前
|
设计模式 Java
小谈设计模式(12)—迪米特法则
小谈设计模式(12)—迪米特法则
|
7月前
|
设计模式
小谈设计模式(5)—开放封闭原则
小谈设计模式(5)—开放封闭原则
下一篇
DataWorks