设计模式原则篇(3):依赖倒转原则---Dependence Inversion Princi

依赖倒转原则，听名字感觉就十分的奇怪。“依赖”是什么？为什么要到转呢？理解这些

首先要从"依赖倒转原则"的定义入手。

依赖倒转原则：

高层模块不应该依赖于底层模块，而是应该依赖于抽象；抽象不应该依赖于具体的

细节；细节应该依赖于抽象。

高层模块和底层模块容易明白。每一个功能模块的实现都是由原则逻辑组成的，不可

分割的原则逻辑就是底层模块，其再组装就是高层模块。那么，抽象和细节有事怎么一回

事呢？这里的抽象就是java中的抽象类、接口，至于细节则就是具体实现类了。因此上述

的三层含义可以概括如下：

1、模块之间的依赖是通过抽象发生的，实现类并不体现其关系，其依赖关系是通过抽

像类、接口体现的。

2、对于接口、抽象类的编码不应该依赖于实现类。

3、实现类具体的行为是依赖于接口、抽象类的。

通俗的讲就是针对接口编程，而不是针对实现编程。

现在反过来去理解“依赖倒转原则”：传统的过程性系统的设计方法倾向于是高层次的依赖于

低层次的模块；抽象层次依赖于具体层次。倒转原则就是把这个依赖关系倒转过来就是“依赖”

倒转的由来。

具体情况如下：错误的依赖关系

倒转过来之后的关系：

不过怎样做到依赖倒转原则呢？

以抽象的方式耦合是实现依赖倒转原则的关键，这里的耦合关系一共有三种：

● 零耦合：如果两个类之间没有耦合关系，则成为零耦合关系

● 具体耦合：耦合关系发生在两个具体的类之间，经由一个类对

另一个类的直接引用造成的。

● 抽象耦合：耦合发生在一个具体类和一个抽象类之间，较之前者更灵活

因为要实现抽象耦合，就必然涉及到继承，因此里氏替换原则就是其前提。

关于里氏替换原则上一篇文章有介绍。

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!