设计模式之依赖倒转原则(DIP)

1.概念

DIP:Dependency Inversion Principle

抽象不应当依赖于细节,细节应当依赖于抽象(说通俗点也就是要针对接口编程,不要针对实现编程;或者要依赖于抽象,不要依赖于具体)。

2.为何叫“依赖倒转”?

传统的过程性系统的设计办法倾向于使高层次的模块依赖于低层次的模块;抽象层次依赖于具体层次。倒转原则则是把这个错误的依赖关系倒过来。

3.如何做到依赖倒转?

以抽象方式耦合是依赖倒转原则的关键。由于一个抽象耦合关系总要涉及到具体类从抽象类继承,并且需要保证在任何引用到基类的地方都可以改换为其子类,所以里氏代换原则是依赖倒转原则的基础不应当依赖于细节,细节应当依赖于抽象(或者要针对接口编程,不要针对实现编程;或者要依赖于抽象,不要依赖于具体)。

三种耦合关系:

零耦合:如果两个类没有耦合关系,就称之为零耦合。

具体耦合:具体性耦合发生在两个具体的(可实例化)类之间,经由一个类对另一个具体类的直接引用造成。

抽象耦合:抽象耦合关系发生在一个具体类和一个抽象类(或者接口)之间,使两个必须发生关系的类之间存在有最大的灵活性。

依赖倒转原则要求客户端依赖于抽象耦合。

抽象不应当依赖于细节;细节应当依赖于抽象。

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

变量被声明时的类型叫做变量的静态类型,也叫做明显类型,变量所引用的对象的真实类型叫做变量的实际类型。

程序在需要引用一个对象时,应当尽可能的使用抽象类型作为变量的静态类型,这就是针对接口编程的含义。

强内聚:像CPU一样,别的厂商木有办法造。因为看不见内部。

松耦合:像CPU的针脚一样,主板厂商知道怎么造主板能用cpu

“高内聚,低耦合”主要是阐述的面向对象系统中,各个类需要职责分离的思想。   
每一个类完成特定的独立的功能,这个就是高内聚。耦合就是类之间的互相调用关系,如果耦合很强,互相牵扯调用很多,那么会牵一发而动全身,不利于维护和扩展。

类之间的设置应该要低耦合,但是每个类应该要高内聚.耦合是类之间相互依赖的尺度.如果每个对象都有引用其它所有的对象,那么就有高耦合,这是不合乎要求的,因为在两个对象之间,潜在性地流动了太多信息.低耦合是合乎要求的:它意味着对象彼此之间更独立的工作.低耦合最小化了修改一个类而导致也要修改其它类的"连锁反应".
内聚是一个类中变量与方法连接强度的尺度.高内聚是值得要的,因为它意味着类可以更好地执行一项工作.低内聚是不好的,因为它表明类中的元素之间很少相关.成分之间相互有关联的模块是合乎要求的.每个方法也应该高内聚.大多数的方法只执行一个功能.不要在方法中添加‘额外‘的指令,这样会导致方法执行更多的函数. 
    
推广开来说,这个思想并不限于类与类之间的关系。模块和模块,子系统之间也都要遵守这个原则,才可以设计出延展性比较强的系统。

3.依赖倒转原则的优缺点:

依赖倒转原则虽然很强大,但却是最不容易实现的。对象的创建很可能要使用对象工厂,以避免对具体类的直接引用,此原则的使用会导致大量的类。

依赖倒转原则假定所有的具体类都是会变化的,这也不总是正确的,有一些具体类可能是相当稳定的,不会发生变化,为此没有必要进行抽象。

时间: 2024-10-09 14:07:31

设计模式之依赖倒转原则(DIP)的相关文章

学习大话设计模式05_依赖倒转原则

依赖到转原则 A.高层模块不应该依赖低层模块.两个都应该依赖抽象. B.抽象不应该依赖细节.细节应该依赖抽象.即:针对接口编程,不要对实现编程. 里氏代换原则: 一个软件实体如果使用的是一个父类的话,那么一定适用于其子类,而且它察觉不出父类对象和子类对象的区别.也就是说,在软件里面,把父类都替换成它的子类,程序的行为没有变化. (子类型必须能够替换掉它们的父类型) 只有当子类可以替换掉父类,软件单位的功能不受影响时,父类才能真正被复用,而子类也能够在父类的基本上增加新的行为. 由于子类型的可替换

大话设计模式之依赖倒转原则

依赖倒转原则: 定义: 在大话中最重要的两句话是:抽象不应该依赖与细节,细节应该依赖于抽象.还有一句是:针对接口编程,不要对实现编程. 问题: 类A直接依赖类B.假如要将类A改为依赖C.则必须通过须要改动类A的代码来达成.但假设,类A是高级模块,负责业务逻辑:类B和类C是低层模块.负责主要的源自操作.这样改变A会给程序带来不必要的风险. 解决方式: 将类A改动为依赖接口I,类B和类C各自实现接口I,类A通过接口I来与类B和C发生纤细,则会大大减少改动A的几率. 基本思想: 用抽象构建框架.用事先

设计模式(5)-----依赖倒转原则

依赖倒转原则 定义 A.高层模块不应该依赖底层模块.两个都应该依赖抽象. B.抽象不应该依赖细节.细节应该依赖抽象. 在面向对象的世界里,所谓的抽象指的就是借口和抽象类,而对于依赖倒转原则自己更深的理解就是“面向接口编程”. 例子 在一个汽车自动检测系统中,该系统可以自动对车子进行run和stop的检测. package com.csdhsm.designpattem.dependence; /** * @Title: JeepCar.java * @Description: 吉普车 * @au

设计模式之依赖倒转原则

抽象不应该依赖细节,细节应该依赖于抽象.说白了,就是要针对接口编程,不要对实现编程.可以用电脑的设计来理解,无论主板,CPU,内存,还是硬盘都是针对接口设计的.如果针对实现设计,内存就要对应到具体每个品牌的主板,就会出现换内存就需要把主板换掉的尴尬. 依赖倒转原则:1.高层模块不应该依赖低层模块,两个都应该依赖抽象. 2.抽象不应该依赖细节,细节应该依赖抽象. 那为什么要叫倒转呢?面向过程开发时,为了使得常用的代码可以复用,一般都会把这些常用代码写成许许多多函数的程序库,这样我们在做新项目的时候

设计模式原则(3)--Dependency Inversion Principle(DIP)--依赖倒转原则

1.定义: 高层模块不应该依赖低层模块,二者都应该依赖其抽象:抽象不应该依赖细节:细节应该依赖抽象. 抽象不应该依赖于细节,细节应当依赖于抽象.换言之,要针对接口编程,而不是针对实现编程. 2.使用场景: 类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成.这种场景下,类A一般是高层模块,负责复杂的业务逻辑:类B和类C是低层模块,负责基本的原子操作:假如修改类A,会给程序带来不必要的风险.即将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C

设计模式之刘伟老师文章学习记录-------------依赖倒转原则

如果说开闭原则是面向对象设计的目标的话,那么依赖倒转原则就是面向对象设计的主要实现机制之一,它是系统抽象化的具体实现.依赖倒转原则是Robert C. Martin在1996年为"C++Reporter"所写的专栏Engineering Notebook的第三篇,后来加入到他在2002年出版的经典著作"Agile Software Development, Principles, Patterns, and Practices"一书中.依赖倒转原则定义如下: 依赖倒

小菜学设计模式——依赖倒转原则

背景 本文标题为什么叫小菜学习设计模式,原因是本文内容主要是学习<大话设计模式>时的笔记摘要部分,当然,并不是记录书中小菜的学习过程,这个完全没有意义,而是指本人学习设计模式的成长之旅. 真诚的希望自己能够从一名小菜成长为一名大鸟! 编写的程序应该满足: 1)可维护 2)可扩展 3)可复用 4)够灵活 废话少说,言归正传,设计模式原则之:依赖倒转原则 书面理解 依赖倒转原则: A.高层次的模块不应该依赖于低层次的模块,他们都应该依赖于抽象. B.抽象不应该依赖于具体,具体应该依赖于抽象. 简单

《大话设计模式》:依赖倒转原则

依赖倒转原则 1,高层模块不应该依赖低层模块,两个都应该依赖抽象. 2,抽象不应该依赖细节,细节应该依赖抽象.针对接口编程,不应该针对实现编程. 里氏代换原则 一个软件实体如果使用的是一个父类的话,那么一定适用于其子类,而且察觉不出父类对象和子类对象的区别.也就是说,在软件里面,把父类都替换成它的子类,程序的行为没有变化. 子类型必须能够替换掉他们的父类型. 只有当子类可以替换掉父类,软件单位的功能不受影响时,父类才能真正被复用,而子类也能够在父类的基础上增加新的行为. 由于子类型的可替换性才使

设计模式--依赖倒转原则

依赖倒转原则又称依赖倒置原则: 抽象不应该依赖细节,细节应该依赖于抽象.说白了,就是针对接口编程,不要针对实现编程. 依赖倒置原则包括三层含义: 1)高层模块不应该依赖低层模块,两者都应该依赖其抽象: 2)抽象不应该依赖细节; 3)细节应该依赖抽象. 看了上面的解释相信大家会和我一样会有一些疑问在脑海里,以下来具体说一说吧: 1)为什么要针对接口编程,而不是针对实现编程呢? 非常easy的一个样例.我们如今使用的电脑有各式的品牌.联想.神舟.戴尔等等, 电脑须要用到鼠标,键盘:如果鼠标.键盘是针