依赖倒置原则(DIP)定义:

高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。

问题由来:

类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成。这种场景下,类A一般是高层模块,

负责复杂的业务逻辑;类B和类C是低层模块,负责基本的原子操作;假如修改类A,会给程序带来不必要的风险。

解决方案:

将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C发生联系,则会大大降低修改类A的几率。

ps:

依赖倒置原则基于这样一个事实:相对于细节的多变性,抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础

搭建起来的架构要稳定的多。抽象指的是接口或者抽象类,细节就是具体的实现类,使用接口或者抽象类的目的是制定

好规范和契约,而不去涉及任何具体的操作,把展现细节的任务交给他们的实现类去完成。

依赖倒置原则的核心思想是面向接口编程,用一个例子来说明面向接口编程比相对于面向实现编程好在什么地方。

举个生活中的例子, 我们每天下班, 可能为了方便亦或锻炼身体, 选择骑单车回家, 对于现在单车, 又有各种各样: mobike, ofo, 小蓝, 小鸣等等...

(用C#代码表达)  定义3个实现, 分别对应的是各种单车品牌。

 public class BlueGoGo
{
public void Go()
{
Console.WriteLine("骑的是小蓝单车");
}
} public class Ofo
{
public void Go()
{
Console.WriteLine("骑的是小黄单车");
}
} public class Mobike
{
public void Go()
{
Console.WriteLine("骑的是摩拜单车");
}
}

然后再定义一个骑行类(Ride)

//骑行类
public class Ride
{
//扫码小蓝骑车
public void ScanCodeByBlueGoGo()
{
BlueGoGo blue = new BlueGoGo();
blue.Go();
} //扫码摩拜单骑车
public void ScanCodeByMoBike()
{
Mobike mo = new Mobike();
mo.Go(); } //扫码小黄骑车
public void ScanCodeByOfo()
{
Ofo ofo = new Ofo();
ofo.Go();
}
}

现在看上去确实也没什么问题, 所以调用一下, 一切正常

仔细看看, 这个代码确实有问题, 针对上面所讲的依赖倒置原则

<类A直接依赖类B, 假如要将类A改为依赖类C,则必须通过修改类A的代码来达成。这种场景下,类A一般是高层模块,

负责复杂的业务逻辑;类B和类C是低层模块,负责基本的原子操作;假如修改类A,会给程序带来不必要的风险。>

正如例子中的 骑行类(Ride) 正是依赖BlueGoGo,MoBike,Ofo类, 如果现在 Ride类要新增一个小鸣单车, 则我们必须要修改Ride的代码,同是添加一个XiaoMing的类达到效果。

 //骑行类
public class Ride
{
//扫码小蓝骑车
public void ScanCodeByBlueGoGo()
{
BlueGoGo blue = new BlueGoGo();
blue.Go();
} //扫码摩拜单骑车
public void ScanCodeByMoBike()
{
Mobike mo = new Mobike();
mo.Go(); } //扫码小黄骑车
public void ScanCodeByOfo()
{
Ofo ofo = new Ofo();
ofo.Go();
} /*
* 该功能位新增的小鸣单车, 必须修改Ride类
*/
public void ScanCodeByXiaoMing()
{
XiaoMing xming = new XiaoMing();
xming.Go();
}
}

像MoBike, BlueGoGo, Ofo, XiaoMing 这些类, 他们都属于底层模块, 负责基本的骑车的动作,  按照依赖倒置的原则, 则不应该修改A, 否则如果在业务量很大的情况下, 则会给程序带来不必要的潜在风险。

用依赖导致的思想怎么去实现 新增小鸣单车而不对高层模块进行修改?

1.将单车的每个Go动作都抽象起来, 分别让他们去做各自的实现。

//修改位抽象的车类
public abstract class abstarctBike
{
public abstract void Go();
} public class BlueGoGo: abstarctBike
{
public override void Go()
{
Console.WriteLine("骑的是小蓝单车");
}
} public class Ofo : abstarctBike
{
public override void Go()
{
Console.WriteLine("骑的是小黄单车");
}
} public class Mobike : abstarctBike
{
public override void Go()
{
Console.WriteLine("骑的是摩拜单车");
}
} public class XiaoMing : abstarctBike
{
public override void Go()
{
Console.WriteLine("骑的是小明单车");
}
}

这时, 我们再把骑行类(Ride)进行改造, 将原有的ScanCodeXXX 都弃用, 用一个全新的ScanCode提供一个抽象类型。

//骑行类
public class Ride
{
//
public void ScanCode(abstarctBike bike)
{
bike.Go();
} /*
* 以下位之前弃用的模式
*/ //扫码小蓝骑车
public void ScanCodeByBlueGoGo()
{
BlueGoGo blue = new BlueGoGo();
blue.Go();
} //扫码摩拜单骑车
public void ScanCodeByMoBike()
{
Mobike mo = new Mobike();
mo.Go(); } //扫码小黄骑车
public void ScanCodeByOfo()
{
Ofo ofo = new Ofo();
ofo.Go();
} /*
* 该功能位新增的小鸣单车, 必须修改Ride类
*/
public void ScanCodeByXiaoMing()
{
XiaoMing xming = new XiaoMing();
xming.Go();
}
}

现在, 我们再调用, 只要指定给Ride对象ScanCode执行的类型就可以实现骑行动作。

这样修改后,无论以后怎样扩展单车类,都不需要再修改Ride类了。这只是一个简单的例子,实际情况中,代表高层模块的Ride类将负责完成主要的业务逻辑,

一旦需要对它进行修改,引入错误的风险极大。所以遵循依赖倒置原则可以降低类之间的耦合性,提高系统的稳定性,降低修改程序造成的风险。

在实际编程中,我们一般需要做到如下3点:

  • 低层模块尽量都要有抽象类或接口,或者两者都有。
  • 变量的声明类型尽量是抽象类或接口。
  • 使用继承时遵循里氏替换原则。

依赖倒置原则的核心就是要我们面向接口编程,理解了面向接口编程,也就理解了依赖倒置。

设计模式六大原则(三):依赖倒置原则(Dependence Inversion Principle)的更多相关文章

  1. 依赖倒置(Dependence Inversion Principle)DIP

    关于抽象类和接口的区别,可以参考之前的文章~http://www.cnblogs.com/leestar54/p/4593173.html using System; using System.Col ...

  2. 7.12 其他面向对象设计原则3: 依赖倒置原则DIP

    其他面向对象设计原则3: 依赖倒置原则DIP  The Dependency Inversion Principle7.1 依赖倒置原则DIP The Dependency Inversion Pr ...

  3. IOS设计模式的六大设计原则之依赖倒置原则(DIP,Dependence Inversion Principle)

    定义 高层模块不应该依赖于低层模块,二者都应该依赖于抽象:抽象不应该依赖细节:细节应该依赖抽象. 定义解读 依赖倒置原则在程序编码中经常运用,其核心思想就是面向接口编程,高层模块不应该依赖低层模块(原 ...

  4. [设计模式]<<设计模式之禅>>关于依赖倒置原则

    依赖倒置原则(Dependence Inversion Principle,DIP)这个名字看着有点别扭,“依赖”还“倒置”,这到底是什么意思?依赖倒置原则的原始定义是 High level modu ...

  5. 设计模式学习--面向对象的5条设计原则之依赖倒置原则--DIP

    一.DIP简介(DIP--Dependency Inversion Principle): 1.高层模块不应该依赖于低层模块,二者都应该依赖于抽象.2.抽象不应该依赖于细节,细节应该依赖于抽象.   ...

  6. Java设计模式(2:单一职责原则和依赖倒置原则详解)

    一.单一职责原则 不要存在多于一个导致类变更的原因.简单来说,就是一个Class/Interface/Method只负责一项职责. 这句话最为重要的就是这一段:一个Class/Interface/Me ...

  7. 最简单直接地理解Java软件设计原则之依赖倒置原则

    理论性知识 定义 依赖倒置原则,Dependence Inversion Principle (DIP) 高层模块不应该依赖低层模块.二者都应该依赖其抽象. 抽象不应该依赖细节,细节应该依赖抽象. 针 ...

  8. 深入理解JavaScript系列(22):S.O.L.I.D五大原则之依赖倒置原则DIP

    前言 本章我们要讲解的是S.O.L.I.D五大原则JavaScript语言实现的第5篇,依赖倒置原则LSP(The Dependency Inversion Principle ). 英文原文:htt ...

  9. 设计模式课程 设计模式精讲 3-4 依赖倒置原则讲解+coding

    1 课程讲解 1.1 定义 1.2 优点 1.3 细节描述 2 代码演练 2.0 代码展示优点 2.1 非面向接口编程 2.2 面向接口编程1 传参 2.3 面向接口编程2 构造函数 2.4 面向接口 ...

随机推荐

  1. Linux学习笔记--cp命令(复制)

    cp:英文名copy,复制的意思. 1. 命令格式: cp [选项] 源文件或文件夹 目标文件或文件夹 cp [选项] 源文件1 源文件2 源文件3 ... 目标文件夹 2. 经常使用选项: &quo ...

  2. RedHat Linux 下安装、测试摄像头

    RedHat Linux 下安装.测试摄像头(全文见附件)     随着视频电话的迅速发展我相信大家一定有过在Windows 下安装摄像头的经历,然而大多数 都不支持Linux .我现以罗技摄像头为例 ...

  3. vue 实现文本域还剩多少字符

    <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8&quo ...

  4. jquery中prop()方法和attr()方法

    接着上一篇笔记的疑惑,找了下prop()方法和attr()方法的区别. 原来query1.6中新加了一个方法prop(),一直没用过它,官方解释只有一句话:获取在匹配的元素集中的第一个元素的属性值. ...

  5. 使用PyV8模块破解网站加密cookie

    PyV8是Chromium中内嵌的javascript引擎,号称跑的最快.PyV8是用Python在V8的外部API包装了一个python壳,这样便可以使python可以直接与javascript操作 ...

  6. jq 监听键盘事件

    其实这个也是挺简单的一些东西.也就是几个参数: 一.首先需要知道的是:         1.keydown()                 keydown事件会在键盘按下时触发. 2.keyup( ...

  7. Yeslab华为安全HCIE七门之--防火墙高级技术(17篇)

    Yeslab 全套华为安全HCIE七门之第三门 防火墙高级技术     课程目录: 华为安全HCIE-第三门-防火墙高级技术(17篇)\1_用户认证_用户_认证域_认证策略.avi 华为安全HCIE- ...

  8. [Python] Problem with Default Arguments

    Default arguments are a helpful feature, but there is one situation where they can be surprisingly u ...

  9. c++中重载、重写、覆盖的区别

    Overload(重载):在C++程序中,可以将语义.功能相似的几个函数用同一个名字表示,但参数或返回值不同(包括类型.顺序不同),即函数重载.(1)相同的范围(在同一个类中):(2)函数名字相同:( ...

  10. 56.如何清除已经设置的npm config配置

    npm config delete registry npm config delete disturl 或者 npm config edit 找到淘宝那两行,删除