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

前端之家收集整理的这篇文章主要介绍了设计模式原则篇(3):依赖倒转原则---Dependence Inversion Principle前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

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

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

依赖倒转原则:

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

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

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

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

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

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

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

像类、接口体现的。

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

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

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

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

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

倒转的由来。

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

倒转过来之后的关系:


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

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

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

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

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

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

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

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

猜你在找的设计模式相关文章