依赖倒置原则、控制反转和依赖注入

1.依赖倒置原则:

  1)上层模块不依赖与下层模块,而是共同依赖于抽象模块(或者接口)。

  2)抽象的东西不能是具象,具象依赖于抽象。

2.控制反转(Inversion of Control):

  是软件运行时的一种行为。比如:对象A依赖于对象B,但是在B并不是直接去创建A,而是从外界取得A。就是说

  一个对象并不直接去创建它所以依赖的其他对象。

3.依赖注入(Dependency Injection):

  是控制反转的一个具体实现。就像上面说的一样,A的创建不是直接在B中创建,而是通过某些框架(比如Autoface)通过构造函数或者属性设置来完成。

  IoC,它把传统上由程序代码直接操控的对象的调用权交给容器,通过容器来实现对象组件的装配和管理。所谓的“控制反转”概念就是对组件对象控制权的

  转移,从程序代码本身转移到了外部容器。

时间: 2024-08-09 22:00:22

依赖倒置原则、控制反转和依赖注入的相关文章

架构设计之依赖倒置、控制反转与依赖注入

名词解释 依赖:一种模型元素之间的关系的描述.例如类A调用了类B,那么我们说类A依赖于类B. 耦合:一种模型元素之间的关系的描述.例如类A调用了类B或类B调用了类A,那么我们说类A与类B有耦合关系. 耦合度:模型元素之间的依赖程度的量化描述. 控制:一种模型元素之间的关系的描述.例如类A调用了类B,那么我们说类A控制类B. 绪论 架构设计的对象一般是类库.框架和应用程序.其工作任务除了类库.框架.应用程序各个模块(类)之间的关系设计之外,还包括类库.框架和应用程序三者之间关系的设计.而依赖倒置.

我曾想深入了解的:依赖倒置、控制反转、依赖注入

大道至简 我们在软件工程中进行的架构设计.模块实现.编码等工作,很多时候说到底就是围绕一件事进行:解耦. 三层架构,MVC,微服务,DDD.我们分析问题,抽象问题,然后划分边界,划分层次. 也是为了让我们的类.模块.系统有更强的复用能力,提高生产效率. 这一次,我想深入了解和探讨我曾经很迷糊,也没有一直仔细了解的:依赖倒置.控制反转.依赖注入 这些概念. 什么是依赖? 通常可以理解为一种需要,需求.需要协助才能完成一件事情. 例如,我们依赖日志服务写日志: public class Contra

依赖倒置、控制反转和依赖注入的区分

依赖倒置(Dependency Inversion Principle).控制反转(Inversion of Control)和依赖注入(Dependency Injection)从思想来讲是统一的,或者说是类似的,有人也说它们是同一个东西. 但是还是可以做一点区分:依赖倒置原则      是进行软件设计时考虑遵循的一个原则.具体为:      (1)上层模块不应该依赖于下层模块,它们共同依赖于一个抽象.      (2)抽象不能依赖于具象,具象依赖于抽象.控制反转是软件运行时体现出来的一个特征

依赖、依赖倒置、控制反转、依赖注入

1.依赖 依赖就是有联系,有地方使用到它就是有依赖它,一个系统不可能完全避免依赖.如果你的一个类或者模块在项目中没有用到它,恭喜你,可以从项目中剔除它或者排除它了,因为没有一个地方会依赖它.下面看一个简单的示例: /// <summary> /// 用户播放媒体文件 /// </summary> public class OperationMain { public void PlayMedia() { MediaFile _mtype = new MediaFile(); Pla

控制反转与依赖注入

关于控制反转和依赖注入的文章和书籍很多,对其定义也解释的也仁者见仁,这里就不赘述了,这是本人(只代表个人观点)理解之后用通俗的例子和平淡的话词为您解释,希望对您有所帮助: 控制反转(IoC/Inverse Of Control):   调用者不再创建被调用者的实例,由spring框架实现(容器创建)所以称为控制反转. 依赖注入(DI/Dependence injection) :   容器创建好实例后再注入调用者称为依赖注入. 当 某个角色(可能是一个Java实例,调用者)需要另一个角色(另一个

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

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

我组织类时无意间遵守了依赖倒置原则

我每次開始写一个小项目的时候,都想把项目中的那些类组织得优雅一些,但最后的代码总是一团糟,这让我非常痛苦.我把希望寄托于设计模式,希望它能帮我解脱.遗憾的是,从接触设计模式到如今,已经快三年了,我的代码就仅仅出现过单例模式. 只是,从今天開始,一切都不一样了,我的代码里多了依赖倒置原则. 在讲依赖倒置原则在我的代码里的详细呈现之前,先总体说一下设计模式六大原则: (1)单一职责原则.说的是一个类应该仅仅干一件事儿. (2)里氏替换原则.说的是,程序中用子类对象替换父类对象.不应该改变程序行为.

依赖倒置原则:避免写出架构糟糕的代码

什么是依赖倒置原则 依赖倒置原则的原始定义为包含三个方面: 高层模块不应该依赖底层模块,两者都应该依赖其抽象 抽象不应该依赖细节 细节应该依赖抽象 高层模块和底层模块可能好理解些,因为每一个逻辑的实现都是由原子逻辑组成的,不可分割的原子逻辑就是低层模块,原子逻辑的再组装就是高层模块.那什么是抽象,什么是细节呢?我们不妨回到 Java 语言本身去找答案吧:在 Java 中,抽象指接口或抽象类,两者均不能被实例化:细节就是实现类,实现类继承抽象类或实现接口,特点在于可被实例化,所以依赖倒置原则在 J

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

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

依赖倒置原则——面向对象设计原则

依赖倒置原则的定义依赖倒置原则(Dependence Inversion Principle,DIP)是 Object Mentor 公司总裁罗伯特·马丁(Robert C.Martin)于 1996 年在 C++ Report 上发表的文章. 依赖倒置原则的原始定义为:高层模块不应该依赖低层模块,两者都应该依赖其抽象:抽象不应该依赖细节,细节应该依赖抽象(High level modules shouldnot depend upon low level modules.Both should