架构整洁之道-08 设计原则-依赖倒置原则DIP

简介: 依赖倒置原则的定义:高层模块不应该依赖低层模块,两者都应该依赖其抽象;抽象不应该依赖细节,细节应该依赖抽象。

依赖倒置

依赖倒置 Dependence Inversion Principle DIP.

High level modules shouldnot depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details. Details should depend upon abstractions。

依赖倒置原则的定义:高层模块不应该依赖低层模块,两者都应该依赖其抽象;抽象不应该依赖细节,细节应该依赖抽象。

其核心思想是:要面向接口编程,不要面向实现编程。

实现方法

依赖倒置的目的是通过面向接口的编程来降低类间的耦合性,所以稳定的软件架构设计应该避免依赖易变的具体类,每个类都尽量使用接口或抽象类,任何类都不从具体类派生。

如何正确使用:

  • 不引用易变的具体实现类。无论静态语言还是动态语言都引用抽象接口类,对对象的创建增加约束,比如使用抽象工厂模式创建对象。
  • 不从易变的具体类实现派生
  • 不覆盖具体实现的方法。当依赖某对象时,对于父类的具体方法都进行覆盖重写
  • 不提任何具体实现和易变类的名字

以下Demo主要通过构造函数方式实现依赖倒置:

class Customer {
    constructor(
        private readonly shop: Shopping
        ){}
        
    async goShop() {
        return console.log(this.shop.sell());
    }
}
​
class Shopping {
    sell(){
     return '小卖部卖东西...';  
    }
}
​
(()=>{
    const shop = new Shopping();
    const cust = new Customer(shop);
    cust.goShop();
})();

依赖倒置的优点

  • 可以降低类之间的耦合性
  • 提高系统的稳定性
  • 减少并行开发引发的风险
  • 提高代码的可读性和可维护性

开闭原则和依赖倒置原则区别

  • 开闭原则:开启扩展,关闭修改;
  • 依赖倒置:抽象不依赖具体,具体应依赖抽象
  • 都是对类/接口的设计

软件设计第一课中讲述:一个好的软件设计者和架构师应该努力去减少接口的易变形,应尝试对于实现类增加函数而不改变接口。这也是我们使用DIP的原因:依赖不变的抽象,扩展具体实现。

目录
相关文章
|
6天前
|
消息中间件 监控 API
深入浅出微服务架构设计原则
在软件开发的宇宙中,微服务如星辰般璀璨,引领着分布式系统的航向。本文将带你穿梭于微服务的星系,探索其背后的设计哲学与实践精髓,从服务边界的划分到数据一致性的保障,再到服务的通信与协作,我们将一同揭开微服务架构高效、可扩展且灵活的秘密。
16 4
|
7天前
|
消息中间件 设计模式 API
后端开发中的微服务架构设计原则
【8月更文挑战第13天】在软件工程的世界中,微服务架构已经成为一种流行的设计模式,它通过将复杂的应用程序分解成一组小的服务来简化开发和部署。本文探讨了微服务背后的设计理念,以及如何在后端开发实践中应用这些原则来构建可扩展、灵活且易于维护的系统。我们将深入讨论服务的划分、通信协议的选择、数据一致性的保障以及容错性策略的实施,旨在为后端开发人员提供一套实用的微服务架构设计指导。
18 1
|
3月前
|
数据中心 网络架构 Python
【计算巢】数据中心的网络架构设计原则
【5月更文挑战第31天】探讨数据中心网络架构设计原则:稳定性是基础,需抵御各种挑战;强调扩展性,适应业务发展;追求高效,确保数据传输速度;注重灵活性,灵活应对变化。简单Python代码示例展示网络节点连接。设计时需具备长远眼光,综合考虑技术方案,以构建坚固高效的信息桥梁。同学们,要持续学习和探索,为信息世界贡献力量!
50 2
|
3月前
|
监控 安全 API
微服务架构下的API网关设计原则
【5月更文挑战第31天】在本文中,我们将深入探讨微服务架构下API网关的设计原则。API网关作为微服务架构的入口点,其设计至关重要。我们将从性能、安全性、可扩展性等方面进行分析,并提出一些实用的设计建议。
|
3月前
|
存储 缓存 运维
云计算架构设计原则
【4月更文挑战第6天】这篇文章介绍了基于云计算的架构设计六大原则:合理部署、业务持续、弹性扩展、性能效率、安全合规和持续运营。
|
12月前
|
设计模式 关系型数据库 数据安全/隐私保护
软件架构设计原则之单一职责原则
单一职责(Simple Responsibility Pinciple,SRP)是指不要存在多于一个导致类变更的原因。假设我们有一个类负责两个职责,一旦发生需求变更,修改其中一个职责的逻辑代码,有可能导致另一个职责的功能发生故障。这样一来,这个类就存在两个导致类变更的原因。如何解决这个问题呢?将两个职责用两个类来实现,进行解耦。后期需求变更维护互不影响。这样的设计,可以降低类的复杂度,提高类的可读性,提高系统的可维护性,降低变更引起的风险。总体来说,就是一个类、接口或方法只负责一项职责。
92 0
软件架构设计原则之单一职责原则
|
12月前
|
设计模式 人工智能 Java
软件架构设计原则之依赖倒置原则
依赖倒置原则(Dependence Inversion Principle,DIP)是指设计代码结构时,高层模块不应该依赖低层模块,二者都应该依赖其抽象。抽象不应该依赖细节,细节应该依赖抽象。通过依赖倒置,可以减少类与类之间的耦合性,提高系统的稳定性,提高代码的可读性和可维护性,并且能够降低修改程序所造成的风险。接下来看一个案例,还是以Course(课程)为例,先来创建一个类Tom:
75 0
|
3月前
|
存储 关系型数据库 uml
00003.七大软件架构设计原则
00003.七大软件架构设计原则
56 0
|
12月前
|
设计模式 关系型数据库
软件架构设计原则之迪米特法则
迪米特原则(Law of Demeter LoD)是指一个对象应该对其他对象保持最少的了解,又叫最少知道原则(Least Knowledge Principle,LKP),尽量降低类与类之间的耦合度。迪米特原则主要强调:只和朋友交流,不和陌生人说话。出现在成员变量、方法的输入、输出参数中的类都可以称为成员朋友类,而出现在方法体内部的类不属于朋友类。
92 1
|
11月前
|
开发者
构建可持续性软件架构:六大设计原则
构建可持续性软件架构:六大设计原则
225 0