Java设计模式之依赖倒转原则精解

目录
  • 1.什么是依赖倒转原则?
  • 2.代码案例
  • 3.依赖关系传递的三种方式和案例举例
    • 3.1 接口传递
    • 3.2 构造方法传递
    • 3.3 setter方法传递
  • 4.依赖倒转原则总结

1.什么是依赖倒转原则?

  • 高层模块不应该依赖低层模块,二者都应该依赖其抽象。
  • 抽象不应该依赖细节,细节应该依赖抽象。
  • 依赖倒转 (倒置) 的中心思想是面向接口编程。
  • 依赖倒转原则是基于这样的设计理念:相对于细节的多变性,抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在Java中,抽象指的是接口或抽象类,细节就是具体的实现类。
  • 使用接口或抽象类的目的是制定好规范,而不涉及任何具体的操作,把展现细节的任务交给他们的实现类去完成。

2.代码案例

package com.szh.principle.inversion;

/**
 *
 */
class Email {
    public String getInfo() {
        return "电子邮件信息: hello,world";
    }
}

// 完成Person接收消息的功能
// 方式1分析
//   1. 简单,比较容易想到
//   2. 如果我们获取的对象是 微信,短信等等,则新增类,同时Person也要增加相应的接收方法
//   3. 解决思路:引入一个抽象的接口IReceiver, 表示接收者, 这样Person类与接口IReceiver发生依赖
//   因为Email, WeiXin 等等属于接收的范围,他们各自实现IReceiver 接口就ok, 这样我们就符号依赖倒转原则
class Person {
    public void receive(Email email ) {
        System.out.println(email.getInfo());
    }
}

public class DependencyInversion {
    public static void main(String[] args) {
        Person person = new Person();
        person.receive(new Email());
    }
}

我们可以根据依赖倒转原则对上面的代码做一个改进,如下:

package com.szh.principle.inversion.improve;

/**
 *
 */
//定义接口
interface IReceiver {
    public String getInfo();
}

class Email implements IReceiver {
    public String getInfo() {
        return "电子邮件信息: hello,world";
    }
}

//增加微信
class WeiXin implements IReceiver {
    public String getInfo() {
        return "微信信息: hello,ok";
    }
}

//方式2
class Person {
    //这里我们是对接口的依赖
    public void receive(IReceiver receiver ) {
        System.out.println(receiver.getInfo());
    }
}

public class DependencyInversion {
    public static void main(String[] args) {
        //客户端无需改变
        Person person = new Person();
        person.receive(new Email());
        person.receive(new WeiXin());
    }
}

3.依赖关系传递的三种方式和案例举例

3.1 接口传递

package com.szh.principle.inversion.improve;

/**
 * 方式1: 通过接口传递实现依赖
 */
 interface IOpenAndClose1 {
    public void open(ITV1 tv); //抽象方法,接收接口
 }

 interface ITV1 { //ITV接口
    public void play();
 }

class OpenAndClose1 implements IOpenAndClose1 {
     @Override
     public void open(ITV1 tv){
         tv.play();
     }
}

 class ChangHong1 implements ITV1 {
	@Override
	public void play() {
		System.out.println("长虹电视机,打开");
	}
 }

public class DependencyPass1 {
    public static void main(String[] args) {
        ChangHong1 changHong = new ChangHong1();
		OpenAndClose1 openAndClose = new OpenAndClose1();
		openAndClose.open(changHong);
    }
}

3.2 构造方法传递

package com.szh.principle.inversion.improve;

/**
 * 方式2: 通过构造方法依赖传递
 */
 interface IOpenAndClose2 {
    public void open(); //抽象方法
 }

 interface ITV2 { //ITV接口
    public void play();
 }

 class OpenAndClose2 implements IOpenAndClose2 {
    public ITV2 tv; //成员

    public OpenAndClose2(ITV2 tv){ //构造器
        this.tv = tv;
    }

    public void open(){
        this.tv.play();
    }
 }

class ChangHong2 implements ITV2 {
    public void play() {
        System.out.println("长虹电视机,打开");
    }
}

public class DependencyPass2 {
    public static void main(String[] args) {
        ChangHong2 changHong = new ChangHong2();
        //通过构造器进行依赖传递
		OpenAndClose2 openAndClose = new OpenAndClose2(changHong);
		openAndClose.open();
    }
}

3.3 setter方法传递

package com.szh.principle.inversion.improve;

/**
 * 方式3: 通过setter方法传递
 */
interface IOpenAndClose3 {
    public void open(); // 抽象方法
    public void setTv(ITV3 tv);
}

interface ITV3 { // ITV接口
    public void play();
}

class OpenAndClose3 implements IOpenAndClose3 {
    private ITV3 tv;

    public void setTv(ITV3 tv) {
        this.tv = tv;
    }

    public void open() {
        this.tv.play();
    }
}

class ChangHong3 implements ITV3 {
    public void play() {
        System.out.println("长虹电视机,打开");
    }
}

public class DependencyPass3 {
    public static void main(String[] args) {
        ChangHong3 changHong = new ChangHong3();
        //通过setter方法进行依赖传递
        OpenAndClose3 openAndClose = new OpenAndClose3();
        openAndClose.setTv(changHong);
        openAndClose.open();
    }
}

4.依赖倒转原则总结

  • 低层模块尽量都要有抽象类或接口,或者两者都有,程序稳定性更好。
  • 变量的声明类型尽量是抽象类或接口,这样我们的变量引用和实际对象间,就存在一个缓冲层,利于程序扩展和优化。
  • 继承时遵循里氏替换原则。(我们后面再说)

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

(0)

相关推荐

  • 详解Java设计模式中的装饰模式

    目录 一.装饰模式的定义和特点 二.装饰模式的结构 三.咖啡点单案例演示 四.总结 一.装饰模式的定义和特点 在软件开发过程中,有时想用一些现存的组件.这些组件可能只是完成了一些核心功能.但在不改变其结构的情况下,可以动态地扩展其功能.所有这些都可以釆用装饰器模式来实现. 就像我们做菜,需要用到调料,菜,刀,火等一系列抽象的组件来最终完成一道菜. 装饰模式的定义: 指在不改变现有对象结构的情况下,动态地给该对象增加一些职责(即增加其额外功能)的模式,它属于对象结构型模式.就增加功能来说,装饰模式

  • Java设计模式之里氏替换原则精解

    1.什么是里氏替换原则? 我们都知道,在面向对象编程中有三大特性(封装.继承.多态),在这里我们来说 继承 这个东西. 继承包含这样一层含义:父类中凡是已经实现好的方法,实际上是在设定规范和契约,虽然它不强制要求所有的子类必须遵循这些契约,但是如果子类对这些已经实现的方法任意修改,就会对整个继承体系造成破坏. 也就是说:继承在给程序设计带来便利的同时,也带来了弊端.比如使用继承会给程序带来侵入性,程序的可移植性降低,增加对象间的耦合性,如果一个类被其他的类所继承,则当这个类需要修改时,必须考虑到

  • Java设计模式之开闭原则精解

    目录 1.什么是开闭原则? 2.违反Ocp代码案例 3.遵守Ocp代码案例 1.什么是开闭原则? 开闭原则(Open Closed Principle)是编程中最基础.最重要的设计原则. 一个软件实体如类,模块和函数应该对扩展开放(对提供方),对修改关闭(对使用方).用抽象构建框架,用实现扩展细节. 当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化. 编程中遵循其它原则,以及使用设计模式的目的就是遵循开闭原则. 2.违反Ocp代码案例 package c

  • java设计模式(实战)-责任链模式

    目录 一:模式说明 二:项目实战 三:源代码 一:模式说明 模式定义:使多个对象都有机会处理请求,从而避免了请求的发送者和接受者之间的耦合关系.将这些对象连成一条链,并沿着这条链传递该请求,直到有对象处理它为止. 责任链模式的重点是在“链”上,由一条链去处理相似的请求在链中决定谁来处理这个请求,并返回相应的结果(取自<设计模式之禅>). 翻译:Client对象调用一个处理者(类)的方法,可能有多个处理者(实现类),但是该对象只需要调用第一个处理者(类)即可,该模式会自动分配谁来处理这个请求:这

  • 详解java设计模式中的门面模式

    门面模式又叫外观模式(Facade Pattern),主要用于隐藏系统的复杂性,并向客户端提供了一个客户端可以访问系统的接口. 我们知道电视剧操作很简单,但是里面的设计和原理很少人明白,这就是因为电视剧的设计应用了门面模式 一个电视剧至少需要有以下几个模块的功能:信号输入.音频处理.视频处理.信号输出等 /** * 射频信号输入 */ public class SignalIn { // } * 音频/视频信号输出 public class SignalOut { * 音频处理 public c

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

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

  • Java设计模式之迪米特原则精解

    目录 1.什么是迪米特原则? 2.违反迪米特原则代码案例 3.遵守迪米特原则代码案例 4.迪米特原则的注意事项 1.什么是迪米特原则? 一个对象应该对其他对象保持最少的了解. 类与类关系越密切,耦合度越大. 迪米特法则(Demeter Principle)又叫最少知道原则,即一个类对自己依赖的类知道的越少越好.也就是说,对于被依赖的类不管多么复杂,都尽量将逻辑封装在类的内部.对外除了提供的public方法,不对外泄露任何信息. 迪米特法则还有个更简单的定义:只与直接的朋友通信. 直接的朋友:每个

  • Java设计模式之职责链模式详解

    目录 前言 一.职责链模式的定义与特点 二.职责链模式的结构 三.职责链模式案例 前言 本文简单介绍了设计模式的一种--职责链模式  一.职责链模式的定义与特点 定义: 为了避免请求发送者与多个请求处理者耦合在一起,于是将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链:当有请求发生时,可将请求沿着这条链传递,直到有对象处理它为止. 比如我们的审批制度,低等级的审批不了的,交给上一级审批,依次类推,直到审批结束. 在责任链模式中,客户只需要将请求发送到责任链上即可,无须关心请求的处

  • Java设计模式之依赖倒转原则精解

    目录 1.什么是依赖倒转原则? 2.代码案例 3.依赖关系传递的三种方式和案例举例 3.1 接口传递 3.2 构造方法传递 3.3 setter方法传递 4.依赖倒转原则总结 1.什么是依赖倒转原则? 高层模块不应该依赖低层模块,二者都应该依赖其抽象. 抽象不应该依赖细节,细节应该依赖抽象. 依赖倒转 (倒置) 的中心思想是面向接口编程. 依赖倒转原则是基于这样的设计理念:相对于细节的多变性,抽象的东西要稳定的多.以抽象为基础搭建的架构比以细节为基础的架构要稳定的多.在Java中,抽象指的是接口

  • Java设计模式之接口隔离原则精解

    1.什么是接口隔离原则? 客户端不应该依赖它不需要的接口,即一个类对另一个类的依赖应该建立在最小的接口范围上. 2.对应代码 上面这张图呢,就违反了接口隔离原则.它对应的代码如下: package com.szh.principle.segregation; /** * */ interface Interface1 { void operation1(); void operation2(); void operation3(); void operation4(); void operati

  • Java设计模式之单一职责原则精解

    1.什么是单一职责原则? 首先我们可以对某个类来说,即一个类应该只负责一项职责.如类A负责两个不同职责: 职责1,职责2.当职责1需求变更而改变A时,可能造成职责2执行错误,所以需要将类A的粒度分解为A1,A2. 我们来看下面这段代码: package com.szh.principle.singleresponsibility; /** * 交通工具类 * 方式1 * 1. 在方式1的run方法中,违反了单一职责原则 * 2. 解决的方案非常的简单,根据交通工具运行方法不同,分解成不同类即可

  • java设计模式七大原则之依赖倒转原则详解

    目录 1.什么是依赖倒转原则? 2.代码案例 3.依赖关系传递的三种方式和案例举例 3.1 接口传递 3.2 构造方法传递 3.3 setter方法传递 4.依赖倒转原则总结 1.什么是依赖倒转原则? 高层模块不应该依赖低层模块,二者都应该依赖其抽象. 抽象不应该依赖细节,细节应该依赖抽象. 依赖倒转 (倒置) 的中心思想是面向接口编程. 依赖倒转原则是基于这样的设计理念:相对于细节的多变性,抽象的东西要稳定的多.以抽象为基础搭建的架构比以细节为基础的架构要稳定的多.在Java中,抽象指的是接口

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

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

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

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

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

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

随机推荐