java的依赖倒置原则你了解多少

目录
  • 依赖倒置原则
  • 案例:
    • 背景:
      • 1.面向实现编程
      • 2.面向接口编程(简单版)
  • 总结

依赖倒置原则

什么是依赖倒置原则:

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

抽象不应该依赖细节,细节应该依赖抽象

针对接口编程,不要针对实现编程

即:

每个类尽量继承自接口或者抽象类

优点:减少类之间的耦合,提高代码的稳定性,代码的可读性维护性。

案例:

背景:

现在有一个用户类叫Ggzx(也就是我),想要学习一些课程,简单的来实现调用学习的方法,然后在一个Test类之中输入学习的内容。但是我暂时只学java和web,但是可能我后面还要学习Spring,SpringMVC…

1.面向实现编程

public class Ggzx {
    public void stduyJava(){
        System.out.println("学习了java课程");
    }
    public void studyWeb(){
        System.out.println("学习了Web课程");
    }
}
public class Test {
    public static void main(String[] args) {
        Ggzx ggzx=new Ggzx();
        ggzx.studyJava();
        ggzx.studyPython();
        ggzx.studyGo();
    }
}

分析:

上面使用的面向实现编程,但是Test作为我们控制的"应用层",也就是高层,而Ggzx作为低层,其实这样在比较简单的例子中,其实是没问题的,因为假如不需要扩展,仅仅是实现两个很简单的功能,并没有必要去面向接口开发,但是一般在开发中通常有很复杂的开发环境和开发需求。

现在如果想添加新的功能,学习其他的课程,怎么办???

继续使用面向实现编程,直接在 Ggzx 类中直接添加新的方法,可以完成这个功能需求。

用上面的方法实现有没有缺点???

1.学习的课程和 Ggzx 类耦合比较严重。是学习的课程只能通过Ggzx 才能得到 。并且是想要学习新的课程也要在 Ggzx 类中不断添加和修改 —>高耦合

2.Ggzx 作为当前 demo 的底层,经常的被改动,高层Test依赖于低层 Ggzx 的实现 ---->对应依赖倒置原则中的:高层过度依赖低层了

2.面向接口编程(简单版)

为了解决上面出现的问题,我们可以考虑把学习的课程抽出来成为一个类。到现在,类和类之间的耦合其实就已经降低很多了。然后将其当做参数传入Ggzx里面,然后调用课程里面的学习方法

//web课程类
public class WebCourse  {
    public void studyCourse() {
        System.out.println("学习了Web课程");
    }
}
//这里是Java课程类
public class JavaCourse {
    public void studyCourse() {
        System.out.println("学习Java课程");
    }
}

当我们写出来这两个类,想要对Ggzx里面的学习方法进行编写的时候,有没有发现其实有一些小问题呢????

Ggzx里面接收这些类的参数是什么??

难道要这样?

//以下是Ggzx类中的内容
    public void studyJava(JavaCourse javaCourse){
    }
    public void studyWeb(WebCourse webCourse){
    }

nonono,如果这样做,虽然当前已经把课程类和 Ggzx 用户剥离一点点了,但是是还是形同虚设,课程类虽然分离开了,但是还是像狗皮膏药一样贴在 Ggzx 类中,但是看着还是很难受,高层 Test 调用方法还是得依赖 Ggzx 里面有什么方法

  • 每次加入新课程,都需要修改底层功能

如何修改???

接口是个好东西,课程类之间是不是都包含同样一个方法,被学习的方法( studyCourse ),那么我们可以将所有课程类都实现一个ICourse课程!

对应上面的问题,我们该传入什么参数能解决问题??可以传入一个接口

改编后的 UML 图解展示(Ggzx 被废弃,用新的 NewGgzx 代替):

(如果没了解过UML类图,或者是纯小白,只需要知道一个大框是一个类,虚线表示实现了箭头方向的接口,小m是方法 即可)

观察上面的UML图

WebCourse 和 JavaCourse 实现自同一个接口 ICourse,每个课程都有自己的 studyXxx 方法。

这样好在什么地方?

课程类和Ggzx类是解耦的,无论你增加多少个课程类,只要实现了ICourse接口,都能直接传入Ggzx的studyMyCourse()方法中

public interface ICourse {
    void studyCourse();
}
public interface ICourse {
    void studyCourse();
}
public class NewGgzx {
	public void studyMyCourse(ICourse iCourse){
		iCourse.studyCourse();
	}
	}

上面就是案例的面向接口编程,我们可以看到,在 NewGgzx 类中,我们可以传入一个实现 ICourse 接口的课程类,我们在Test类中调用的时候,只需要传入一个课程类即可调用学习方法,这样当想扩展新的内容,只需要创建一个新的课程类实现 ICourse 即可

Test使用

NewGgzx newGgzx =new NewGgzx();
newGgzx.studyMoocCourse(new WebCourse());
newGgzx.studyMoocCourse(new com.ggzx.design.priciple.dependenceiversion.JavaCourse());

从面向实现到面向接口,我们处理问题的方法改变了:

  • 开始时,我们需要考虑在Test类中调用Ggzx里面的哪一种学习方法,即注重调用什么方法能够实现特定的课程
  • 到面向接口编程,我们考虑传入什么课程即可实现学习

当业务需求拓展时,拓展方法也改变了:

  • 面向实现:需要改变底层的代码来协调我们需要使用的功能,用上面的例子来解释就是:当你想要学习一个课程,你就需要改变你底层的实现,增加新的代码
  • 面向接口:想学习什么课程,不会对其他课程造成影响,也不会影响到低层的Ggzx 。实际操作就是增加一门新的课程即可,实现接口之后,传入这个类到Ggzx的方法中就可以学习这一门课了

相对于细节的多变性,抽象的东西更稳定,以抽象为基础搭建的架构比以细节搭建的架构更加稳定

总结

本篇文章就到这里了,希望能够给你带来帮助,也希望您能够多多关注我们的更多内容!

(0)

相关推荐

  • 详解Java设计模式编程中的依赖倒置原则

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

  • java 设计模式之依赖倒置实例详解

    本文实例讲述了java 设计模式之依赖倒置.分享给大家供大家参考,具体如下: 依赖倒置的概念我也是在一篇博文上理解的,我觉得很精辟,所以收录在我的博客中. 类A 依赖 类B,之后根据需求 类A 变换为依赖 类C,这时候我们认为类A 是高层模块, 类B 和 类C 是低层模块. 什么是高层模块?什么是底层模块? 高层模块你可以理解为控制层,负责复杂的业务逻辑. 低层模块你可以理解为数据层,负责基本的原子操作. 什么意思? 我举个例子. 比如大胃王比赛. 在这场比赛中的规则是比赛谁吃馒头吃的最多.有参

  • java面向对象设计原则之单一职责与依赖倒置原则详解

    目录 单一职责概念 实现 拓展 依赖倒置原则概念 示例 拓展 单一职责概念 不要存在多于一个导致类变更的原因,也就是说每个类应该实现单一的职责,否则就应该把类拆分.交杂不清的职责将使得代码牵一发而动全身,导致代码混涩难懂,不易修改.难以扩展和复用.如:以前开发C/S程序中的胖客户端程序,就是将人机交互逻辑.业务加工处理逻辑和数据库操作逻辑混合在一起. 实现 单一职责原则是进行类的划分和封装的基本原则,进行类的具体抽象.尽量做到,类的功能单一和清晰化. 1.根据机能划分,使用封装来创建对象之间的分

  • Java设计模式七大原则之依赖倒置原则详解

    目录 定义 案例 需求 方案一 方案二 对比分析 总结 定义 依赖倒转原则,又称依赖倒置原则(Dependence Inversion Principle),又称DIP原则,即:上层模块不应该依赖底层模块,它们都应该依赖于抽象,抽象不应该依赖于细节,细节应该依赖于抽象.抽象对代码来说即接口或者抽象类 细节对代码来说即实现类.换句话说 依赖倒转原则的核心的理念 相对于细节来说,抽象要稳定得多.要求我们 面向接口编程,进行设计. 案例 需求 工作人员接收微信老板发来的加班消息 方案一 定义工作人员W

  • java的依赖倒置原则你了解多少

    目录 依赖倒置原则 案例: 背景: 1.面向实现编程 2.面向接口编程(简单版) 总结 依赖倒置原则 什么是依赖倒置原则: 高层模块不应该依赖低层模块,二者都应该依赖其抽象 抽象不应该依赖细节,细节应该依赖抽象 针对接口编程,不要针对实现编程 即: 每个类尽量继承自接口或者抽象类 优点:减少类之间的耦合,提高代码的稳定性,代码的可读性维护性. 案例: 背景: 现在有一个用户类叫Ggzx(也就是我),想要学习一些课程,简单的来实现调用学习的方法,然后在一个Test类之中输入学习的内容.但是我暂时只

  • PHP面向对象五大原则之依赖倒置原则(DIP)详解

    本文实例讲述了PHP面向对象五大原则之依赖倒置原则(DIP).分享给大家供大家参考,具体如下: 什么是依赖倒置呢?简单地讲就是将依赖关系倒置为依赖接口,具体概念如下: 1.上层模块不应该依赖于下层模块,它们共同依赖于一个抽象(父类不能依赖子类,它们都要依赖于抽象类) 2.抽象不能依赖于具体,具体应该要依赖于抽象. 注意,这里的接口不是狭义的接口. 为什么要依赖接口?因为接口体现对问题的抽象,同时由于抽象一般是相对稳定的或者是相对变化不频繁的,而具体是易变的.因此依赖抽象是实现代码扩展和运行期内绑

  • 深入理解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

  • 深入浅析python3 依赖倒置原则(示例代码)

    场景 针对园区停车信息,需要对各个公司提供的停车数据进行整合并录入自家公司的大数据平台 数据的录入无外乎就是对数据的增删改查 下面上一个常规的写法(未符合依赖倒置),整合来自 长安和丰田 的停车数据 class Changan(object): def __init__(self): self.type = 'changan' def ca_add(self): print('%s 新增' % self.type) def ca_del(self): print('%s 删除' % self.t

  • C#实现六大设计原则之依赖倒置原则

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

  • C#编程之依赖倒置原则DIP

    一.前言 我们先来看看传统的三层架构,如下图所示: 从上图中我们可以看到:在传统的三层架构中,层与层之间是相互依赖的,UI层依赖于BLL层,BLL层依赖于DAL层.分层的目的是为了实现“高内聚.低耦合”.传统的三层架构只有高内聚没有低耦合,层与层之间是一种强依赖的关系,这也是传统三层架构的一种缺点.这种自上而下的依赖关系会导致级联修改,如果低层发生变化,可能上面所有的层都需要去修改,而且这种传统的三层架构也很难实现团队的协同开发,因为上层功能取决于下层功能的实现,下面功能如果没有开发完成,则上层

  • Java依赖倒转原则_动力节点Java学院整理

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

随机推荐