依赖倒置原则DIP(Dependence Inversion Principle)

依赖倒置原则的含义

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

什么是高层模块?低层模块

每一个原子逻辑就是低层模块,原子逻辑再组就是高层模块。

什么是抽象和细节

抽象是抽象类,不可被实例化。

细节是实现类,比如实现的接口或继承抽象类的子类,可以被实例化。

表现在Java语言中就是面向接口编程

  • 模块间的依赖是通过抽象来实现的,具体的实现类之间不能发生直接的依赖。
  • 接口或抽象类不能依赖与实现类。
  • 实现类依赖接口或抽象类。

我们假设有三个类,一个为场景类,一个为司机类,一个为奔驰类。通过这三个类我们便可以实现司机开动汽车这个场景。如图



具体的实现代码如下

司机类

package des.DIP;
//司机类
public class Driver {
//司机驾驶车 紧耦合
public void drive(Benze benze){
benze.run();
}
//司机驾驶宝马车 紧耦合
public void drive(BMW bmw){
bmw.run();
}
}

奔驰类

package des.DIP;
//奔驰车
public class Benze {
public void run(){
System.out.print("奔驰车开始运行...");
}
}

场景类

package des.DIP;
//场景类
public class Client {
public static void main(String[] args){
//创建一个司机
Driver zs = new Driver();
//创建一个奔驰车
Benze benze = new Benze();
//司机可以开奔驰车
zs.drive(benze);
//假设此时增加一个宝马车呢?还要再增加一个方法,并且重新创建
//一个还好若是很多呢?难道要在司机类声明很多方法吗?
BMW bmw = new BMW(); } }
package des.DIP;
//宝马车
public class BMW {
//宝马车当然也可以开动
public void run(){
System.out.print("宝马车开动...");
}
}

程序正常的写法就是如此,但是如果我们考虑下面一个问题,司机并不是只会开着一辆Benze牌的车,假如我们再假如一个BMW(宝马)牌的车,我们传统的做法就是再新建一个类,然后再司机类中再添加一个drive BMW的方法。假如我们要添加无数品牌的汽车呢,难道还要再司机类中添加无数的drive方法吗?他们都有着相同的方法名,只是传入的汽车型号不同。

显然,传统的drive方法的写法,具有紧耦合性,只要车型变更,就不能再使用了。其导致的结果就是系统的可维护性大大降低,可读性也大大降低


解决方法

使用依赖倒置原则

DIP第一种方法 接口注入法

建立两个接口,IDriver和ICar



此时业务的场景类就可以改写成如下

package des.DIP;

public class Client1 {
public static void main(String[] args){
//创建一个司机
/**
* 此处明确两个概念:
* IDriver 叫做表面类型, Driver1 叫做实际类型 或称抽象类型和实际类型
*
* 此后所有的操作均是对抽象接口的操作,具体屏蔽了细节
*/
IDriver ds = new Driver1();
ICar c = new Bmw1();
ds.drive(c); }
}

表面类型和实际类型: IDriver 叫做表面类型, Driver1 叫做实际类型 或称抽象类型和实际类型

下面是接口类和实现类参考代码:

package des.DIP;
//司机接口
public interface IDriver {
//司机可以驾驶汽车,什么汽车不用管即抽象类(松耦合)
public void drive(ICar car);
}
package des.DIP;
//抽象汽车类
public interface ICar {
//汽车启动
public void run();
}
package des.DIP;

public class Driver1 implements  IDriver {
@Override
public void drive(ICar car) {
car.run();
}
}
package des.DIP;

public class Bmw1 implements  ICar {
@Override
public void run() {
System.out.print("宝马车开始运行...");
}
}
package des.DIP;

public class Benze1 implements  ICar {
@Override
public void run() {
System.out.print("奔驰车开始运行...");
}
}

假设我们项目中有两个类是依赖关系,此时我们只需要定义两个抽象类就可以独立开发了。

DIP第二种方法 构造函数传递依赖对象

package des.DIP;
//司机接口
public interface IDriver {
//司机可以驾驶汽车,什么汽车不用管即抽象类(松耦合)
public void drive(ICar car);
/***************************/
public void drive();
}
package des.DIP;

public class Driver1 implements  IDriver {
/******************************************************/
private ICar car;
//构造函数注入
public Driver1(ICar _car){
this.car = _car;
}
@Override
public void drive() {
this.car.run();
}
/******************************************************/
@Override
public void drive(ICar car) {
car.run();
} }
IDriver ds1 = new Driver1(new Bmw1());
ds.run();

运行结果



构造函数依赖注入理解图示





DIP第三种方法 setter方法传递依赖对象







代码参考

package des.DIP;
//司机接口
public interface IDriver {
public void setCar(ICar car);
public void drive(); }
package des.DIP;
public class Driver1 implements IDriver {
/******************************************************/
private ICar car;
@Override
public void setCar(ICar car) {
this.car.run();
} @Override
public void drive() {
this.car.run();
} }
package des.DIP;

public class Client1 {
public static void main(String[] args){ IDriver ds1 = new Driver1();
ds1.setCar(new Bmw1());
ds1.drive(); }
}

DIP总结

  • DIP本质就是通过抽象类来实现彼此独立,互不影响
  • 依赖倒置的核心是面向接口编程,即上面的第一种方法。
  • 依赖倒置的具体使用规则如下
    • 每个类尽量有接口或抽象类,或者二者都有。
    • 变量的表面类型尽量是接口或抽象类。
    • 任何类不应该从具体类派生。
    • 尽量不要覆写基类的方法。
    • 结合里氏替换原则进行。
  • 依赖倒置需要审时度势,而不是永远抓住这个原则不放,任何一个原则的优点都是有限的。

对于倒置的理解

从反面讲:什么是正置?如上例子,我们开什么型号的车,就依赖什么样型号的车。不存在什么抽象类与接口,直接单独建立即可,需要什么建立什么。但是依赖倒置?就是对车进行抽象,抽象出类和接口,建立抽象间的依赖。

六大设计原则(三)DIP依赖倒置原则的更多相关文章

  1. 《设计模式》-原则三:依赖倒置原则(DIP)

    这几天晚上回来都去玩了!没有坚持学习.真的好惭愧! 非常自责 后面一定要坚持 一气呵成  争取每天学一点,把这个学完. 今天主要是看了一下  设计模式中的 原则三: 依赖倒置原则(DIP) 官方是这样 ...

  2. C#软件设计——小话设计模式原则之:依赖倒置原则DIP

    前言:很久之前就想动笔总结下关于软件设计的一些原则,或者说是设计模式的一些原则,奈何被各种bootstrap组件所吸引,一直抽不开身.群里面有朋友问博主是否改行做前端了,呵呵,其实博主是想做“全战”, ...

  3. 【面向对象设计原则】之依赖倒置原则(DIP)

    依赖倒转原则(Dependency Inversion  Principle, DIP):抽象不应该依赖于细节,细节应当依赖于抽象.换言之,要针对抽象(接口)编程,而不是针对实现细节编程. 开闭原则( ...

  4. 【设计模式六大原则3】依赖倒置原则(Dependence Inversion Principle)

      定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象:抽象不应该依赖细节:细节应该依赖抽象. 问题由来:类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成.这种场景下,类 ...

  5. 面象对象设计原则之五:依赖倒置原则(The Dependency Inversion Principle,DIP)

    如果说开闭原则是面向对象设计的目标的话,那么依赖倒转原则就是面向对象设计的主要实现机制之一,它是系统抽象化的具体实现.依赖倒转原则是Robert C. Martin在1996年为“C++Reporte ...

  6. DIP依赖倒置原则

    一.定义 1.高层模块不应该依赖低层模块,二者都应该依赖抽象 2.抽象不应该依赖于细节.细节应该依赖于抽象 二.层次化 1.简单介绍 结构良好的面向对象架构都具有清晰的层次定义,每个层次通过一个定义良 ...

  7. 九 DIP 依赖倒置原则

    首先看定义: 1.高层模块不依赖于低层模块,两者都应该依赖于抽象层 2.抽象不能依赖于细节,细节必须依赖于抽象 首先,模块是个抽象的概念,可以大到一个系统中的子系统作为一个模块,也可以是某个子系统中的 ...

  8. 第2章 面向对象的设计原则(SOLID):3_依赖倒置原则(DIP)

    3. 依赖倒置原则(Dependence Inversion Principle,DIP) 3.1 定义 (1)要依赖抽象,不要依赖具体的实现类.简单的说就是对抽象(或接口)进行编程,不要依赖实现进行 ...

  9. 依赖倒置原则(Dependency Inversion Principle)

    很多软件工程师都多少在处理 "Bad Design"时有一些痛苦的经历.如果发现这些 "Bad Design" 的始作俑者就是我们自己时,那感觉就更糟糕了.那么 ...

随机推荐

  1. CSS弹性盒子的基本用法

    .container { width: 302px; height: 302px; border: 1px solid; display: flex } .item { width: 100px; h ...

  2. JAVA远程通信的几种选择(RPC,Webservice,RMI,JMS的区别)

    RPC(Remote Procedure Call Protocol) RPC使用C/S方式,采用http协议,发送请求到服务器,等待服务器返回结果.这个请求包括一个参数集和一个文本集,通常形成&qu ...

  3. Linux时间子系统之三:jiffies

    1. jiffies背景介绍 jiffies记录了系统启动以来,经过了多少tick. 一个tick代表多长时间,在内核的CONFIG_HZ中定义.比如CONFIG_HZ=200,则一个jiffies对 ...

  4. org.springframework.web.servlet.PageNotFound

    2017-07-11 16:36:13.489 WARN [http-nio-8032-exec-16]org.springframework.web.servlet.PageNotFound -Re ...

  5. Spring Batch 专题

    如今微服务架构讨论的如火如荼.但在企业架构里除了大量的OLTP交易外,还存在海量的批处理交易.在诸如银行的金融机构中,每天有3-4万笔的批处理作业需要处理.针对OLTP,业界有大量的开源框架.优秀的架 ...

  6. 超实用的JavaScript代码段 Item3 --图片轮播效果

    图片轮播效果 图片尺寸 统一设置成:490*170px; 一.页面加载.获取整个容器.所有放数字索引的li及放图片列表的ul.定义放定时器的变量.存放当前索引的变量index 二.添加定时器,每隔2秒 ...

  7. css的div垂直居中的方法,百分比div垂直居中

    前言 我们都知道,固定高宽的div在网页中垂直居中很简单,相信大家也很容易的写出来,但是不是固定高宽的div如何垂直居中呢?我们在网页布局,特别是手机等web端网页经常是不固定高宽的div,那么这些d ...

  8. app后端设计(5)-- 表情的处理

    在app的应用中,文字中夹带表情是个很常见,那么,在后台处理表情的时间,我遇到过下面两个问题: 1. 表情在mysql的存储. 表情的utf8编码,有时是有4个字节的,所以在一般的utf编码是没法存储 ...

  9. MySQL数据库简识

    MySQL:关系型数据库      (由瑞典MySQL AB公司开发,后来被Sun公司收购,Sun公司后来又被Oracle公司收购,目前属于Oracle旗下产品)         开源 免费 不要钱 ...

  10. QM4_Probability

    Basic Concepts Probability concepts Terms Random variable A quantity whose possible values are uncer ...