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

目录
  • 定义
  • 案例
    • 需求
    • 方案一
    • 方案二
    • 对比分析
  • 总结

定义

依赖倒转原则,又称依赖倒置原则(Dependence Inversion Principle),又称DIP原则,即:上层模块不应该依赖底层模块,它们都应该依赖于抽象,抽象不应该依赖于细节,细节应该依赖于抽象。抽象对代码来说即接口或者抽象类 细节对代码来说即实现类。换句话说 依赖倒转原则的核心的理念 相对于细节来说,抽象要稳定得多。要求我们 面向接口编程,进行设计。

案例

需求

工作人员接收微信老板发来的加班消息

方案一

定义工作人员Worker.java

/**
 * 工作人员
 * @author:liyajie
 * @createTime:2022/1/30 20:08
 * @version:1.0
 */
public class Worker {

    /**
     * 工作人员接收消息
     * @author: liyajie
     * @date: 2022/1/30 20:10
     * @param weChat
     * @return void
     * @exception:
     * @update:
     * @updatePerson:
     **/
    public void getMessage(WeChat weChat){
        weChat.sendMessage();
    }
}

定义微信消息类WeChat.java

/**
 * 微信消息类
 * @author:liyajie
 * @createTime:2022/1/30 20:07
 * @version:1.0
 */
public class WeChat {

    /**
     * 微信发送的消息
     * @author: liyajie
     * @date: 2022/1/30 20:10
     * @param
     * @return void
     * @exception:
     * @update:
     * @updatePerson:
     **/
    public void sendMessage(){
        System.out.println("微信上,老板找你加班了");
    }
}

定义测试类Test1.java

public class Test1 {

    public static void main(String[] args) {
        new Worker().getMessage(new WeChat());
    }
}

方案二

定义消息接口IMessage.java

/**
 * 消息接口
 * @author:liyajie
 * @createTime:2022/1/30 20:15
 * @version:1.0
 */
public interface IMessage {
    void sendMessage();
}

定义微信消息类WeChatNew.java

/**
 * 微信消息类
 * @author:liyajie
 * @createTime:2022/1/30 20:07
 * @version:1.0
 */
public class WeChatNew implements IMessage{

    /**
     * 微信发送的消息
     * @author: liyajie
     * @date: 2022/1/30 20:10
     * @param
     * @return void
     * @exception:
     * @update:
     * @updatePerson:
     **/
    @Override
    public void sendMessage(){
        System.out.println("微信上,老板找你加班了");
    }
}

定义飞书类FeiShu.java

/**
 * 飞书消息类
 * @author:liyajie
 * @createTime:2022/1/30 20:16
 * @version:1.0
 */
public class FeiShu implements IMessage{

    @Override
    public void sendMessage() {
        System.out.println("飞书上,老板喊你加班了");
    }
}

定义工作人员类WorkerNew.java

/**
 * 工作人员类
 * @author:liyajie
 * @createTime:2022/1/30 20:18
 * @version:1.0
 */
public class WorkerNew {
    /**
     * 工作人员接收消息
     * @author: liyajie
     * @date: 2022/1/30 20:10
     * @param iMessage
     * @return void
     * @exception:
     * @update:
     * @updatePerson:
     **/
    public void getMessage(IMessage iMessage){
        iMessage.sendMessage();
    }
}

定义测试类Test2.java

public class Test2 {
    public static void main(String[] args) {
        // 微信
        new WorkerNew().getMessage(new WeChatNew());
        // 飞书
        new WorkerNew().getMessage(new FeiShu());
    }
}

对比分析

方案一违反了依赖倒置原则,如果功能需求扩展,比如说需要扩展一种飞书发送消息,我们需要新增一个飞书类,并实现发送消息的功能,工作人员的类也需要修改接收消息的方法,客户端也需要进行相应的修改,改动大,风险大。

方案二遵守了依赖倒置原则,同样的需求扩展,抽象一个公共的消息接口,所有的微信,飞书等发送消息的类只要实现该接口,重写发送消息的方法,工作人员的接收消息方法以消息接口为入参,客户端只需要传入相应的消息实体类,扩展方便,耦合低。

总结

通过上面两个案例,我们可以得到以下结论:

1.低层模块尽量都要有抽象类或接口,或者两者都有,

2.程序稳定性更好,变量的声明类型尽量是抽象类或者接口,这样我们的变量引用和实际对象间,就存在一个缓冲层, 利于程序扩展和优化

到此这篇关于Java设计模式七大原则之依赖倒置原则详解的文章就介绍到这了,更多相关Java依赖倒置原则内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Java设计模式之责任链模式的示例详解

    目录 应用场景 实际代码案例 无模式情况下的代码 采用责任链模式优化代码 采用建造者+责任链模式优化代码 责任链模式优缺点 责任链模式是将链中的每一个节点看做是一个对象,每个节点处理的请求均不相同,且内部自动维护下一个节点对象,当一个请求从链式的首段发出时,会沿着链的路径依次传递给每一个节点对象,直至有对象处理这个请求位置,属于行为模式. 这里需要注意的是每个节点都能对对象进行一定的处理(也可以不处理),处理完成之后节点再进行判断还要进行后续处理还是说传递给下一个节点. 应用场景 首先举一个日常

  • Java设计模式之装饰模式原理与用法实例详解

    本文实例讲述了Java设计模式之装饰模式原理与用法.分享给大家供大家参考,具体如下: 装饰模式能在不必改变原类文件和使用继承的情况下,动态地扩展一个对象的功能.它是通过创建一个包装对象,也就是装饰来包裹真实的对象.JDK中IO的设计就用到了装饰模式,通过过滤流对节点流进行包装来实现功能的扩展. 装饰模式的角色的组成: ① 抽象构件(Component)角色:给出一个抽象接口,以规范准备接收附加工功能的对象.(InputStream.OutputStream) ② 具体构件(Concrete Co

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

  • Java设计模式之策略模式定义与用法详解

    本文实例讲述了Java策略模式定义与用法.分享给大家供大家参考,具体如下: 一. 定义: 定义一系列算法,把他们一个一个封装起来,并且使他们可以相互替换. 二. 优点: (1)上下文(Context)和具体策略(ConcreteStrategy)是松耦合关系,因此上下文只需要知道他要使用某一个实现  Strategy接口类的实例,但不需要知道是哪个类. (2)策略模式满足开闭原则,当增加新的具体类时,不需要修改上下文类的代码,上下文即可以引用新的具体策略的实例. 三. 实例: 下面就通过一个问题

  • JAVA设计模式之访问者模式原理与用法详解

    本文实例讲述了JAVA设计模式之访问者模式.分享给大家供大家参考,具体如下: 访问者模式: 一个作用于某对象结构中各元素的操作,使你可以在不改变各元素类数据结构的前提下增加作用于这些元素的新操作. 结构对象是访问者模式必备条件,且这个结构对象必须存在遍历自身各个对象的方法. 适用于:数据结构相对稳定,把数据结构和作用与其上的其它操作解耦,使得操作相对自由. 优点: 1.符合单一职责原则 2.扩展性良好:元素类可以通过接受不同的访问者来实现对不同操作的扩展. 缺点: 1.如果要增加新元素,则会让操

随机推荐