设计模式学习之依赖倒置原则

依赖倒置原则,即抽象不应该依赖细节,细节应该依赖于抽象。其实就是要针对接口编程,不要对实现编程。

为什么是依赖倒置?在面向对象开发时,为了使常用的代码可以复用,通常会把这些常用的代码封装成函数库,这样就可以在不同的业务代码中调用这些库,使得代码得到复用。但是,如果在设计的时候不合理,高层的业务模块直接调用,就会使得高层的业务模块直接依赖底层的函数库。

但是,在开发的过程中,我们会发现,有很多高层的业务模块是一样的。如果像上面那样,直接依赖底层模块,这些一样的业务模块很难得到复用。

比如在数据库连接的例子中,高层模块调用数据库函数访问数据库。某个业务刚开始时,因为业务量不大,需要存储的数据量也不大,使用MySQL进行数据存储就可以满足。随着业务的发展,需要存储的数据量急剧增加,需要换成Oracle数据库。因为业务模块直接调用的是MySQL的函数库,如果想要切换,即使有现成Oracle函数库,也需要修改业务模块,去重新调用Oracle的函数库。

出现上面的情况,是因为业务模块依赖于底层的数据库访问模块。要想解决这个问题,需要在高层的业务模块与底层的数据库访问模块之间再抽象一层,使得高层的业务模块和底层的数据库访问模块都面向这个抽象进行开发。

那么为什么这样就可以解决这个问题呢?要弄清楚原因,需要理解里氏替换原则。

里氏替换原则,就是一个软件实体如果使用的是一个父类的话,那么一定适用于其子类,而且它察觉不出父类对象和子类对象的区别。也就是说,把父类都替换成它的子类,程序的行为没有变化。即:子类型必须能够替换掉它们的父类型。

理解了里氏替换原则,再回到业务模块访问数据库的例子中。如果在设计的时候,抽象出一层数据库访问的接口,在接口中定义与数据库相关的方法。业务模块调用接口中的方法,底层模块不管是MySQL数据库还是Oracle数据库的相关代码都实现接口中的方法。这样在切换数据库的时候,业务模块的调用不需要做任何更改,只需要切换成Oracle的数据源就可以了。

依赖倒置可以说是面向对象设计的标志,用哪种语言来编写程序不重要,如果编写时考虑的都是如何针对抽象编程而不是针对细节编程,即程序中所有的依赖关系都是终止与抽象类或者接口,那就是面向对象的设计,反之那就是过程化的设计了。

ps:刚开始写代码的时候,遇到一个问题是,总是先想到怎么实现,用哪个api可以做到。这样的结果就是,问题虽然解决了,但是写的代码就是一次性的。谁也不是一开始就能往设计模式上思考,这需要不断的积累经验,慢慢地转变思维。

原文地址:https://www.cnblogs.com/wgyang/p/12688802.html

时间: 2024-10-08 23:04:20

设计模式学习之依赖倒置原则的相关文章

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

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

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

依赖倒置原则(Dependence Inversion Principle) 依赖倒置原则(DIP)的基本概念 原始定义 高层模块不应该依赖低层模块,两者都应该依赖其抽象 抽象不应该依赖细节 细节应该依赖抽象 Java中的具体含义 模块间的依赖通过抽象发生 实现类之间不发生直接的依赖关系 其依赖关系通过接口或者抽象类产生 接口或抽象类不依赖于具体实现 实现类依赖接口或抽象类 依赖倒置(DIP)的好处 采用DIP可以减少类之间的耦合性,提高稳定性,降低并行开发带来的风险,提高代码的可读性和可维护性

学习设计模式 - 六大基本原则之依赖倒置原则

设计模式总共有六大基本原则,统称为SOLID (稳定)原则,分别是S-单一职责原则(Single Responsibility Principle), O-开闭原则(Open closed Principle),L-里氏替换原则(Liskov Substitution Principle),L-迪米特法则(Law of Demeter),I-接口隔离原则(Interface Segregation Principle),D-依赖倒置原则(Dependence Invension Principl

设计模式六大原则: 老板是如何减轻负担的 -- 依赖倒置原则

很多创业公司都对外宣称"扁平化管理",什么是"扁平化管理"呢?请看下面这张架构图: 因为人少,老板直接管理着采购.销售.人力跟 IT 等人员,虽然累了点,但部门少.人不多也还好. 但是随着公司规模发展,每次新加入人员老板都要去认识.沟通,出现问题还得去约出去喝个茶,老板发现自己的时间都浪费在这些琐事,容易耽搁事不说,还发挥不出更大价值. 这时他决定招一些经理替自己分别管理各个部门,自己只要管理这些经理就好了. 于是新的架构图是这样的: 老板这下子省心多了,有问题直接

设计模式六大原则(3)--依赖倒置原则

定义: 高层次的模块不应该依赖于低层次的模块,两者都应该依赖于抽象接口:抽象接口不应该依赖于具体实现.而具体实现则应该依赖于抽象接口.依赖倒置原则英文全称为Dependence Inversion Principle,简称为DIP. 问题由来: 类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成.这种场景下,类A一般是高层模块,负责复杂的业务逻辑:类B和类C是低层模块,负责基本的原子操作:假如修改类A,会给程序带来不必要的风险. 解决方案: 将类A修改为依赖接口I,类B和

ASP.NET 设计模式中依赖倒置原则

依赖倒置原则 A.高层次的模块不应该依赖于低层次的模块,他们都应该依赖于抽象. B.抽象不应该依赖于具体,具体应该依赖于抽象. 依赖倒置原则 A.高层次的模块不应该依赖于低层次的模块,他们都应该依赖于抽象. B.抽象不应该依赖于具体,具体应该依赖于抽象. 目录 1概述 2意图 3代码实现 4结构图 1概述编辑 所谓依赖倒置原则(Dependence Inversion Principle)就是要依赖于抽象,不要依赖于具体.简单的说就是要求对抽象进行编程,不要对实现进行编程,这样就降低了客户与实现

设计模式六大原则(3):依赖倒置原则(转载)

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

设计模式六大原则---依赖倒置原则(DIP)

定义 依赖倒置原则(Dependency Inversion Principle) 核心思想:依赖于抽象     具体体现: 体现一:高层模块不应该依赖低层模块.两个都应该依赖抽象. 体现二:抽象不应该依赖细节.细节应该依赖抽象. 依赖倒置原则告诉我们:细节是多变的,而抽象是相对稳定的.所以我们编程的时候要注重抽象的编程,而非细节编程. 实例 1.AGP插槽:主板和显卡之间的关系的抽象.主板和显卡通常是使用AGP插槽来连接的,这样,只要接口适配,不管是主板还是显卡更换,都不是问题. 2.驾照:司

设计模式六大原则之依赖倒置原则

一.概念: 依赖倒置原则英文缩写DIP(Dependence Inversion Principle)原始定义:High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions. 翻译过来就三层含义