我所理解的依赖注入,控制反转,面向切面

依赖注入(Dependency Injection)

简单来说,一般的java或者面向对象思想的程序的架构,大量使用了“组合”这一实现方式,也就是在一个对象内部持有了别的对象的引用,来实现多个对象的交互。这些引用一般有程序员控制。回想起我的五子棋,确实如此,最简单的方式就是持有引用。

但这会导致一个很明显的问题:代码耦合度过大,换句话说,本来该分成一块一块的代码,全部因为持有引用耦合在了一起。一个方法名字参数要修改,可能持有这个对象的所有地方的代码都需要修改。同时维护起来会很困哪,错误由各个地方的引用导致。再者违背了面向对象的思想,一个东西内部也许从逻辑上和某个对象无关,可是却为了方便持有了其引用。

Spring In Action里面写骑士类的例子很好。

那么解决方法是什么呢?那就是依赖一种注入关系,具体需要持有引用的时候“注入”一个引用。其实这一种思想也不是啥特别冷僻的东西。在构造器中传入引用赋值给一个实例变量也就是一种注入。不过这么做不好。因为会让问题复杂化。更理想的方式是通过xml文件装配它。

面向切面(Aspect Oriented Programming)

一些程序中,有的逻辑模块可能在多个地方都会被使用。比如日志,安全等。这会导致两个问题。

1,如果这类逻辑要修改,可能到处都要修改。2,你的代码会变得混乱,因为不仅要完成自己本来的功能,还要去写日志等等。

而面向切面是说:把这种逻辑模块定义为“切面”。在xml文件中定义这个切面,并且控制在切面时程序的行为,“写日志”或者“验证安全性”等等。

控制反转(Inversion of Control)

使用一个Spring容器通过依赖注入控制各个组件的耦合。也就是说你写好了组件,不需要你去自己控制他们的依赖关系,哪个类又持有哪个类的对象,哪个类里面又要声明一个对象,而是把他们都放到一个容器里面,容器替你做这个(把组件组合起来)。

有两种实现形式:Bean工厂,应用上下文。其中第一种过于低级。目前主要使用的是第二种。第二种直接理解就是通过xml文件控制组件的耦合关系。

时间: 2024-10-09 15:25:59

我所理解的依赖注入,控制反转,面向切面的相关文章

Helloworld之Spring依赖注入/控制反转(DI/IoC)版

Helloworld之Spring依赖注入/控制反转(DI/IoC)版 作者:雨水, 日期:2014-10-29 摘要:本文主要用于培训初学者理解Spring中的依赖注入的基本概念. 先介绍依赖注入的基本概念,然后以构造器注入为例实现了Helloworld实例. Spring依赖注入/控制反转 在我们通常的编程中,如果类A要依赖类B,通常是由A来创建一个B的实例.而Spring将创建B的实例的工作交给Spring容器来完成,然后注入A,因此称为依赖注入(DI, Dependency Inject

PHP关于依赖注入(控制反转)的解释和例子说明

PHP关于依赖注入(控制反转)的解释和例子说明 发表于2年前(2014-03-20 10:12)   阅读(726) | 评论(1) 8人收藏此文章, 我要收藏 赞2 阿里云双11绽放在即 1111 元红包即刻开抢!»   摘要 自从听到依赖注入这个设计模式,感觉很高大上,无奈楼主的眼光一直局限在国内框架上,也很少去关注设计模式方面的文章,直到某天遇到了laravel后,发现它手册里重点强调了一个名为“依赖注入”和“容器”的概念,但是对于这两个概念,手册里并未做基本的解释,所以楼主只能另外查找相

C#依赖注入控制反转IOC实现详解

原文:C#依赖注入控制反转IOC实现详解 IOC的基本概念是:不创建对象,但是描述创建它们的方式.在代码中不直接与对象和服务连接,但在配置文件中描述哪一个组件需要哪一项服务.容器负责将这些联系在一起. 举个例子,组件A中有类ClassA,组件B中有接口IB和其对应的实现类B1和B2. 那么,现在ClassA需要利用IB接口来做一些事情,例如: public class ClassA { public void DoSomething() { IB b = ??? b.DoWork(); }} 现

分层,工厂模式,依赖注入控制反转

1.分层:就如同一个人自己制造一个锤子,自己动手丰衣足食.你需要他就自己new一个该实例.无法实现二者之间的松耦合 2.工厂模式:一个人需要一个锤子,他找工厂,工厂帮他造了一个锤子.工厂给你制造的锤子,但是如何造的你不需要知道.你直接调用该接口就可以了,具体你不需要知道.调用者无须关心被调用者具体实现过程,只需要找到符合某种标准(接口)的实例,即可使用 3.依赖注入:一个人需要一个锤子,他打电话给卖锤子的叫他送货上门.你喜欢哪家的锤子,直接叫哪家送货上门就OK.用者无须自己定位工厂,程序运行到需

Spring进阶之路(1)-Spring核心机制:依赖注入/控制反转

我们常常会遇到这样一种情景.就是在我们开发项目的时候常常会在一个类中调用其它的类中的方法,来完毕我们期望的任务.大部分的情况下往往会採用在当前需要的这个类里面new一个实例出来.然后调用他的方法,那么这种话会有个问题.就是有一天我想改变下这个类,改为其它的名称.那么这时候必需要做的是同一时候去调用方的类文件里改变这个改变的类的名称.这种情况是由于代码的耦合带来了后期维护成本的添加,那么spring的出现就能够非常好的起到解耦的作用,而他的核心机制就是依赖注入. 依赖注入与控制反转 依赖注入:对于

大话依赖倒置?控制反转?依赖注入?面向接口编程

那些年,空气中仿佛还能闻到汉唐盛世的余韵,因此你决不允许自己的脸上有油光,时刻保持活力.然而,你一定曾为这些“高深术语”感到过困扰——依赖倒置•控制反转•依赖注入•面向接口编程.也许时至今日,你仍对它们一知半解.不过就在今天,这一切都将彻底改变!我将带领你以一种全新的高清视角进入奇妙的编程世界,领略涵泳在这些“高深术语”中的活泼泼的地气,以及翩跹于青萍之末的云水禅心. ·内聚 内聚,通俗的来讲,就是自己的东西自己保管,自己的事情自己做. 经典理论告诉我们,程序的两大要素:一个是数据(data),

/laravel IOC理解以及依赖注入

废话不说直接上实例 //laravel IOC理解以及依赖注入 DIinterface SuperModuleInterface{    /**      * 超能力激活方法      *      * 任何一个超能力都得有该方法,并拥有一个参数      *@param array $target 针对目标,可以是一个或多个,自己或他人      */     public function activate(array $target); }class XPower implements S

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

好的文章,总是担心消失,自己保存一遍,这里是原文 向依赖关系宣战 依赖倒置.控制反转和依赖注入辨析在<道法自然——面向对象实践指南>一书中,我们采用了一个对立统一的辩证关系来说明“模板方法”模式—— “正向依赖 vs. 依赖倒置”(参见:<道法自然>第15章[王咏武, 王咏刚 2004]).这种把“好莱坞”原则和 “依赖倒置”原则等量齐观的看法其实来自于轻量级容器PicoContainer主页上的一段话: “控制反转(Inversion of Control)的一个著名的同义原则是

通俗简述 依赖倒置?控制反转?依赖注入?面向接口编程 的思想

不管怎样我们都是为了提倡高内聚和低耦合的思想,这么多种思想是不是看那些概念头晕的不行呢? 这里我们主要列举吃饭的例子让大家更直观的理解这几个概念,现在有顾客(客户端)与餐厅(服务端)两个对象 依赖倒置: 餐厅建立订餐通道  (本来是顾客依赖餐厅炒菜的,开通饿了吗后餐厅就倒过来依赖ele的订单去炒菜了) 控制反转IOC(Inversion Of Control):  改成自助餐厅(以前餐厅炒的菜分量太少了,现在菜都摆出来了你可以自己选择量多的菜了) 依赖注入DI(Dependency Inject