依赖倒置之我见

  .net 程序员对面向对象设计原则以及设计模式的重视似乎不如Java,包括许多有经验.net的程序员,也并没有将面向对象的思想渗透进项目中。我本身就是这样一个例子。C#和Java都是面向对象的语言,设计模式对两者是通用的,今天就来谈一谈我对面向对象设计原则之一—依赖倒置原则的理解,之所以选择这个原则,因为之前对这个原则的理解很是模糊。

  首先,依赖倒置的标准定义:

  高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。

  这个定义听得人云里雾里,不知所云。究其原因,是几个概念不清楚。

  1、依赖,什么叫依赖?

  依赖是程序模块(普通类、抽象类、接口)的一种关系,主要包括以下几种情况。

  a、ClassA中某个方法的参数类型是ClassB;  这种情况成为耦合;
  b、ClassA中某个方法的参数类型是ClassB的一个属性; 这种情况成为紧耦合;
  c、ClassA中某个方法的实现实例化ClassB;
  d、ClassA中某个方法的返回值的类型是ClassB;

  2、倒置,为什么叫倒置?

  倒置是相对于我们的一般思路而言的。一般情况下,高层模块是依赖低层模块的。比如A书高层模块类,B是低层模块类,如果A调用B,那就要再A中实例化一个B的对象。这样,A就会依赖B。而依赖倒置做的就是要解除这种依赖,用的方法就是两者都依赖于抽象。

时间: 2024-11-05 11:24:15

依赖倒置之我见的相关文章

依赖倒置原则(Dependency Inversion Principle)

很多软件工程师都多少在处理 "Bad Design"时有一些痛苦的经历.如果发现这些 "Bad Design" 的始作俑者就是我们自己时,那感觉就更糟糕了.那么,到底是什么让我做出一个能称为 "Bad Design" 的设计呢? 绝大多数软件工程师不会在设计之初就打算设计一个 "Bad Design".许多软件也在不断地演化中逐渐地降级到了一个点,而从这个点开始,有人开始说这个设计已经腐烂到一定程度了.为什么会发生这些事情呢?

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

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

面向对象设计原则之四:依赖倒置原则

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

设计原则之依赖倒置原则

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

依赖倒置原理

程序的基本架构应该是一个具有稳定依赖关系的抽象层. 程序的具体实现依赖于稳定的抽象层. 这样才能保证程序的稳定性和可扩展性. http://blog.csdn.net/coolingcoding/article/details/8043265 依赖于抽象:建议不依赖于具体类,即程序中所有的依赖关系都应该终止于抽象类或者接口. 层次化:所有结构良好的面向对象构架都具有清晰的层次定义,每个层次通过一个定义良好的.受控的接口向外提供一组内聚的服务. 全称:“Dependence Inversion P

第2章 面向对象的设计原则(SOLID):3_依赖倒置原则

3. 依赖倒置原则(Dependence Inversion Principle,DIP) 3.1 定义 (1)要依赖抽象,不要依赖具体的实现类.简单的说就是对抽象(或接口)进行编程,不要依赖实现进行编程,这样就降低了客户与实现模块间的耦合.包含3层含义: ①高层模块不应依赖低层模块,两者都应该依赖于抽象 ②抽象不应该依赖细节 ③细节应该依赖于抽象 (2)何为“高层模块”和“低层模块” ①“低层模块”:每个逻辑的实现都是原子逻辑组成,不可分割的原子逻辑就是低层模块.一般和具体实现相关. ②“高层

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

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

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

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

单一职能、开放封闭、里氏替换替换、接口隔离、依赖倒置

Object Oriented Design Principles Marla Sukesh, 8 Apr 2013    4.91 (155 votes) Rate this: vote 1vote 2vote 3vote 4vote 5   This article is intended for who have at least basic idea about Object oriented programming. Who is Audience? This article is i