深入理解依赖倒置原则

何为依赖导致原则?

Robert C. Martin在他的著作《敏捷软件开发:原则、模式与实践》中有这样的两句描述

1.High-level modules should not depend onlow-level modules. Both should depend on abstractions.(高层模块不应该依赖于低层模块,二者都应该依赖于抽象)

2.Abstractions should not depend upondetails. Details should depend upon abstractions.(抽象不应该依赖于具体实现细节,而具体实现细节应该依赖于抽象)

即,模块类之间的依赖是基于抽象类的,实现类之间不能有直接的依赖关系,其依赖关系是通过接口或者抽象类产生的。

其核心思想是:要面向接口编程,不要面向实现编程。

基本概念

抽象与细节

在Java中,抽象就是指接口或者抽象类,两者都是不能直接被实例化的;细节就是实现类,实现接口或者继承抽象类而产生的就是细节,以关键字new产生对象。

高层与低层

通俗来讲高层模块就是调用端,低层模块就是具体实现类。

具体实现

先看下不符合依赖导致原则会产生什么后果。

比如一个司机开奔驰车:

public class Driver{

  public void drive(Benz benz){

    benz.run();

  }

}

public class Benz{

  public void run(){

    System.out.println("奔驰开始运行...")

  }

}

public class Test{
  public static void main(Sting[] args){
    Driver zhangsan = new Driver();

    Benz benz = new Benz();

    zhangsan.drive(benz);
  }
}
这样zhangsan 就可以开奔驰了,但是如果zhangsan明天要开宝马的车呢?

public class BMW{

  public void run(){

    System.out.println("宝马车开始运行....");

  }

}

他不能开,因为张三没有开宝马车的方法,除非要改driver类的方法。张三作为一个司机,居然没法开别的品牌的车,这不符合常理。

下面引入了依赖倒置原则

创建司机接口

public interface IDriver{
  public void drive(ICar car);
}

司机类实现司机接口

public class Driver implements IDriver{
  public void drive(ICar car){
    car.run();
  }
}

定义汽车接口,具体车类实现接口

public interface ICar{
  public void run();
}

public class Benz implements ICar{
  public void run(){
    System.out.println("奔驰骑车开始运行....");
  }
}

public class BMW implements ICar{
  public void run(){
    System.out.println("宝马骑车开始运行....");
  }
}

测试

这里是高层业务逻辑,它对底层模块的依赖(关联)都建立在抽象上。

public class Client{
  public static void main(String[] args){
    IDriver zhangsan = new Driver();
    ICar benz = new Benz();
    ICar bmw = new BMW();

    zhangsan.drive(benz);

    zhangSan.drive(bmw);
  }
}

这样就实现了司机可以开任何品牌的汽车,添加新的品牌不需要修改司机类。

依赖倒置是指导代码解耦的一个原则,通过增加一个抽象层来解耦低层和高层。

参考链接

https://cloud.tencent.com/developer/news/17567

https://blog.csdn.net/u013862108/article/details/79054620

原文地址:https://www.cnblogs.com/hhd-shuai/p/12535685.html

时间: 2024-10-17 08:01:20

深入理解依赖倒置原则的相关文章

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

前言 本章我们要讲解的是S.O.L.I.D五大原则JavaScript语言实现的第5篇,依赖倒置原则LSP(The Dependency Inversion Principle ). 英文原文:http://freshbrewedcode.com/derekgreer/2012/01/22/solid-javascript-the-dependency-inversion-principle/ 依赖倒置原则 依赖倒置原则的描述是: A. High-level modules should not

对依赖倒置原则(DIP)及Ioc、DI、Ioc容器的一些理解

.概述 所谓依赖倒置原则(Dependence Inversion Principle)就是要依赖于抽象,不要依赖于具体.简单的说就是要求对抽象进行编程,不要对实现进行编程,这样就降低了客户与实现模块间的耦合,并由此引申出IoC.DI以及Ioc容器等概念. 2.意图 面向过程的开发,上层调用下层,上层依赖于下层,当下层剧烈变动时上层也要跟着变动,这就会导致模块的复用性降低而且大大提高了开发的成本. 面向对象的开发很好的解决了这个问题,一般情况下抽象的变化概率很小,让用户程序依赖于抽象,实现的细节

依赖倒置原则的理解

1.问题由来:类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成.这种场景下,类A一般是高层模块,负责复杂的业务逻辑:类B和类C是低层模块,负责基本的原子操作:假如修改类A,会给程序带来不必要的风险. 2.解决方案:将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C发生联系,则会大大降低修改类A的几率.(其实换成接口,可能下面的很多代码都不需要变了,如果还是A,B的对象实例,那么下面的代码可能会发生修改.) 3.依赖倒置原则针对的是接口编程

对依赖倒置原则(DIP)及Ioc、DI、Ioc容器的一些理解(转)

所谓依赖倒置原则(Dependence Inversion Principle)就是要依赖于抽象,不要依赖于具体.简单的说就是要求对抽象进行编程,不要对实现进行编程,这样就降低了客户与实现模块间的耦合,并由此引申出IoC.DI以及Ioc容器等概念. 面向过程的开发,上层调用下层,上层依赖于下层,当下层剧烈变动时上层也要跟着变动,这就会导致模块的复用性降低而且大大提高了开发的成本. 面向对象的开发很好的解决了这个问题,一般情况下抽象的变化概率很小,让用户程序依赖于抽象,实现的细节也依赖于抽象.即使

设计模式六大原则: 老板是如何减轻负担的 -- 依赖倒置原则

很多创业公司都对外宣称"扁平化管理",什么是"扁平化管理"呢?请看下面这张架构图: 因为人少,老板直接管理着采购.销售.人力跟 IT 等人员,虽然累了点,但部门少.人不多也还好. 但是随着公司规模发展,每次新加入人员老板都要去认识.沟通,出现问题还得去约出去喝个茶,老板发现自己的时间都浪费在这些琐事,容易耽搁事不说,还发挥不出更大价值. 这时他决定招一些经理替自己分别管理各个部门,自己只要管理这些经理就好了. 于是新的架构图是这样的: 老板这下子省心多了,有问题直接

设计模式之禅-依赖倒置原则

个人blog 此篇博文地址:http://www.sanyinchenblog.com/?p=167 依赖倒置原则(DIP): demo(https://github.com/sanyinchen/UMLDemo) 1.高层模块不应该依赖底层模块 2.抽象不应该依赖细节 3.模块间的依赖不是通过实现类发生的,而是由抽象类发生的 4.接口或者抽象类不依赖于细节 5.实现类依赖于接口或抽象类 书中给出的demo是Driver(司机)开Car(车)的场景. 从uml图中我们可以很清楚的看到ICar和I

设计模式六大原则(3)--依赖倒置原则

定义: 高层次的模块不应该依赖于低层次的模块,两者都应该依赖于抽象接口:抽象接口不应该依赖于具体实现.而具体实现则应该依赖于抽象接口.依赖倒置原则英文全称为Dependence Inversion Principle,简称为DIP. 问题由来: 类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成.这种场景下,类A一般是高层模块,负责复杂的业务逻辑:类B和类C是低层模块,负责基本的原子操作:假如修改类A,会给程序带来不必要的风险. 解决方案: 将类A修改为依赖接口I,类B和

设计模式六大原则(3):依赖倒置原则

依赖倒置原则 定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象:抽象不应该依赖细节:细节应该依赖抽象. 问题由来:类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成.这种场景下,类A一般是高层模块,负责复杂的业务逻辑:类B和类C是低层模块,负责基本的原子操作:假如修改类A,会给程序带来不必要的风险. 解决方案:将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C发生联系,则会大大降低修改类A的几率. 依赖倒转原则(Dependency

设计模式 之 设计的 六大原则(3) 依赖倒置原则

依赖倒置原则 定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象:抽象不应该依赖细节:细节应该依赖抽象. 问题由来:类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成.这种场景下,类A一般是高层模块,负责复杂的业务逻辑:类B和类C是低层模块,负责基本的原子操作:假如修改类A,会给程序带来不必要的风险. 解决方案:将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C发生联系,则会大大降低修改类A的几率. 依赖倒置原则基于这样一个事实:相对于