设计模式之依赖倒转原则

抽象不应该依赖细节,细节应该依赖于抽象。说白了,就是要针对接口编程,不要对实现编程。可以用电脑的设计来理解,无论主板,CPU,内存,还是硬盘都是针对接口设计的。如果针对实现设计,内存就要对应到具体每个品牌的主板,就会出现换内存就需要把主板换掉的尴尬。

依赖倒转原则:1.高层模块不应该依赖低层模块,两个都应该依赖抽象。 2.抽象不应该依赖细节,细节应该依赖抽象。

那为什么要叫倒转呢?面向过程开发时,为了使得常用的代码可以复用,一般都会把这些常用代码写成许许多多函数的程序库,这样我们在做新项目的时候去调用这些低层的函数就可以了。但这样做就有可能出问题,我们做新项目时,发现业务逻辑和高层模块都是一样的,但客户却希望使用不同的数据库或存储信息的方式,这时就麻烦了。我们希望再次利用这些高层模块,但高层模块是与低层的数据库绑定在一起的,没办法复用。而如果不管高层模块还是低层模块都依赖于抽象,具体一点就是接口或抽象类,只要接口是稳定的,那么任何一个更改都不用担心其他受到影响。这就使得无论高层还是低层都可以很容易地被复用,这才是最好的方法。

但为什么依赖了接口或抽象类就不怕更改了呢?这里涉及了里氏代换原则。

里氏代换原则是Barbara Liskov女士在1988年发表的。白话翻译就是一个软件实体如果使用的是一个父类的话,那么一定适用于其子类,而且察觉不出父类对象和子类对象的区别。也就是说,在软件里面,把父类都替换成子类,程序的行为没有变化。

里氏代换原则:子类型必须能够替换掉他们的父类型。

这时学继承就要理解的相关概念。也正是有了这个原则,使得继承复用成为了可能。只有当子类可以替换掉父类,软件单位的功能不受到影响时,父类才能真正被复用,而子类也能在父类的基础上增加新的行为。

说白了,依赖倒转就是除了约定的接口,谁也不要依靠谁,这样大家都可以灵活自如。

原文地址:https://www.cnblogs.com/shicaiyou/p/9209186.html

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

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

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

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

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

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

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

1.概念 DIP:Dependency Inversion Principle 抽象不应当依赖于细节,细节应当依赖于抽象(说通俗点也就是要针对接口编程,不要针对实现编程:或者要依赖于抽象,不要依赖于具体). 2.为何叫"依赖倒转"? 传统的过程性系统的设计办法倾向于使高层次的模块依赖于低层次的模块:抽象层次依赖于具体层次.倒转原则则是把这个错误的依赖关系倒过来. 3.如何做到依赖倒转? 以抽象方式耦合是依赖倒转原则的关键.由于一个抽象耦合关系总要涉及到具体类从抽象类继承,并且需要保证在

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

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

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

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

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

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

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

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

设计模式原则(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"一书中.依赖倒转原则定义如下: 依赖倒