设计模式中的依赖倒置原则具体是怎样的？

本文共计2400个文字，预计阅读时间需要10分钟。

1. 基本介绍 1.1 概念 高层模块不依赖于一个整体化、细化化的低层模块，而是通过一个抽象的规范/标准建立两者之间的依赖关系。简言之，不依赖具体实现，而是依赖规范。

1.基本介绍 1.1.概念

高层模块不能依赖于一个“具体化、细节化”的低层模块，而是通过一个抽象的“规范/标准”建立两者之间的依赖关系，简言之就是：不依赖于实现，而是依赖于抽象。这里“实现”一词有的地方也称为“细节”，在编码中主要体现的是我们根据业务模型具体自定义的普通类，比如：员工类、商品类等。而其中的“抽象”一词是指定的接口或抽象类。

1.2.高层与低层

下面我们通过传统的三层架构作为背景来理解“依赖倒置原则”中的高层与低层的含义。

在分层架构中，高层是相对而言的，对于上面三层架构图中而言最高层是“表示层”，相对于“业务逻辑层”它的高层是“表示层UI”，相对于“数据访问层”它的高层则是“业务逻辑层”。

低层同样也是相对而言的，对于上面三层架构图中而言最低层是“数据访问层”，相对于“业务逻辑层”它的低层是“数据访问层”，相对于“表示层”它的低层则是“业务逻辑层”。

那么简单来说高层就相对于一个使用者，低层就相当于一个被使用者。

1.3.依赖倒置原则在分层架构中的体现

在早期比较传统的项目中，三层架构的分层通常都是上图的形式：表示层直接依赖于一个具体实现、非抽象的业务逻辑层，业务逻辑层对下层的依赖同样如此。这种分层实际上在依赖上就是违背了“依赖倒置原则”，因为它都是依赖的一些具体的实现，而非抽象。