Java 设计模式(十二) 依赖倒置原则(DIP)

依赖倒置原则(Dependence Inversion Principle)

依赖倒置原则(DIP)的基本概念

原始定义

  • 高层模块不应该依赖低层模块,两者都应该依赖其抽象
  • 抽象不应该依赖细节
  • 细节应该依赖抽象

Java中的具体含义

  • 模块间的依赖通过抽象发生

    • 实现类之间不发生直接的依赖关系
    • 依赖关系通过接口或者抽象类产生
  • 接口或抽象类不依赖于具体实现
  • 实现类依赖接口或抽象类

依赖倒置(DIP)的好处

  • 采用DIP可以减少类之间的耦合性,提高稳定性,降低并行开发带来的风险,提高代码的可读性可维护性

    • 通过抽象(接口或者抽象类)使各个类和模块的实现彼此独立,不互相影响,实现模块之间的松耦合
    • DIP是开闭原则实现的基础

例讲DIP

比如我们有一个场景,学生要用笔写做作业。我们如果直接实现,那么当需求改变,学生要用笔画画的时候,我们就要修改作业类,那么就不符合开闭原则,而且每次拓展都会破坏之前的类,这样是不友好的,那么如何根据DIP来设计这个场景呢?

抽象出接口,并利用抽象接口建立联系

interface Tool{
    public void doWork( Job job );
}

interface people{
    public void use ( Tool tool , Job job );
}

interface Job{
    public void finish();
}

我们抽象出了人,工作,任务三个抽象接口,然后我们利用人使用工具完成工作的场景对三个抽象接口建立关系

分别实现具体的逻辑

class Student1 implements Person{

    @Override
    public void use(Tool tool, Job job) {
        System.out.print("Student use ");
        tool.doWork(job);
    }
}

class Pencil implements Tool{

    @Override
    public void doWork(Job job) {
        System.out.print("Pencile to do ");
        job.finish();
    }
}

class HomeWork implements Job{

    @Override
    public void finish() {
        System.out.println("Homework!!");
    }
}

三个类可以并行实现,完全没有耦合关系,实现程序的模块化和并行开发

那么我们测试一下:

public class DIPTest {

    public static void main ( String [] args ){
        Person student = new Student1();
        Tool pencil = new Pencil();
        Job homeWork = new HomeWork();
        student.use(pencil,homeWork);
    }
}

当我们需要实现同样关系的新的类时,只需要拓展就可以了,比如老师用讲义授课依旧可以采取这种模式,可以按照模块进行开发,在团队开发项目的时候效果明显

现实中的经典范例

TDD( Test Driving Developing)测试驱动开发

就是利用一种契约的模式:

  • 先提供接口
  • 然后利用接口的关系和方法写好单元测试类
  • 然后再写实现类,这对提高代码质量有非常大的帮助,特别适合研发类的项目或在项目成员整体水平比较低的情况下采用
时间: 2024-10-07 19:42:43

Java 设计模式(十二) 依赖倒置原则(DIP)的相关文章

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

前言:很久之前就想动笔总结下关于软件设计的一些原则,或者说是设计模式的一些原则,奈何被各种bootstrap组件所吸引,一直抽不开身.群里面有朋友问博主是否改行做前端了,呵呵,其实博主是想做“全战”,即各方便都有战斗力.关于设计模式,作为程序猿的我们肯定都不陌生.博主的理解,所谓设计模式就是前人总结下来的一些对于某些特定使用场景非常适用的优秀的设计思路,“前人栽树,后人乘凉”,作为后来者的我们就有福了,当我们遇到类似的应用场景的时候就可以直接使用了.关于设计模式的原则,博主将会在接下来的几篇里面

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

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

C#编程:依赖倒置原则DIP

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

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

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

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

个人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

深入理解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设计模式十二--State(状态模式)

状态模式(State Pattern)是设计模式的一种,属于行为模式. 定义(源于Design Pattern):当一个对象的内在状态改变时允许改变其行为,这个对象看起来像是改变了其类. 状态模式主要解决的是当控制一个对象状态的条件表达式过于复杂时的情况.把状态的判断逻辑转移到表示不同状态的一系列类中,可以把复杂的判断逻辑简化.意图:允许一个对象在其内部状态改变时改变它的行为适用场景: 1.一个对象的行为取决于它的状态,并且它必须在运行时刻根据状态改变它的行为. 2.一个操作中含有庞大的多分支结

六大设计原则(三)DIP依赖倒置原则

原文:六大设计原则(三)DIP依赖倒置原则 依赖倒置原则DIP(Dependence Inversion Principle) 依赖倒置原则的含义 高层模块不能依赖低层模块,二者都应该依赖其抽象. 抽象不应该依赖于细节. 细节应该依赖抽象. 什么是高层模块?低层模块? 每一个原子逻辑就是低层模块,原子逻辑再组就是高层模块. 什么是抽象和细节? 抽象是抽象类,不可被实例化. 细节是实现类,比如实现的接口或继承抽象类的子类,可以被实例化. 表现在Java语言中就是面向接口编程 模块间的依赖是通过抽象