首页 > 代码库 > IoC概述

IoC概述

---------------siwuxie095

   

   

   

   

   

   

   

IoC,即 Inversion of Control,控制反转,它是 Spring 容器的内核

   

AOP、声明式事务等功能都是在此基础上开花结果,即 都依赖于 IoC

   

IoC 涉及代码解耦、设计模式、代码优化等问题的考量

   

   

从以下三方面来深入了解 IoC:

   

· IoC 的初步理解

· IoC 的注入类型

· IoC 的注入方式

   

   

   

   

IoC 的初步理解

   

   

IoC 概念重要却比较晦涩难懂,通过如下实例来说明:

   

实例场景:电影《无间道》中刘德华所饰演的角色刘建明在天台的对白

   

即:电影:无间道--->角色:刘建明--->演员:刘德华

   

   

在传统的编程模式中,是剧本和演员直接耦合,即 剧本直接指定刘德华来表演

   

技术分享

   

   

显然,在以上剧本中,作为具体角色饰演的刘德华直接侵入到

剧本中,使剧本和演员直接耦合在了一起

   

一个明智的编剧,在剧情创作时,应该围绕故事的角色来进行,

而不应该考虑角色具体的饰演者,这样才能在剧本投拍时,自

由的选择演员,而并非绑定在刘德华一个人身上

   

   

通过以上分析,发现需要为主人公刘建明(角色)定义一个接口

   

技术分享

   

   

引入剧本角色刘建明。剧本情节就通过角色来展开,在拍摄时,

角色由演员来饰演,就如上图中无间道、刘建明、和刘德华三

者之间的关系

   

在上图中,无间道同时依赖刘建明和刘德华,

并没有达到期望:剧本仅依赖于角色

   

   

但角色必须通过具体的演员才能拍摄完成,如何让刘德华和剧本

无关,又能完成刘建明的具体动作呢?可以引入导演

   

在引入导演之后,剧本和饰演者完全解耦

   

技术分享

   

   

首先,建立一个导演类,然后导演选择一个剧本:无间道,同时为剧本指定

一个角色:刘建明,让刘建明插入到无间道中,最后让刘德华来饰演刘建明

   

通过引入导演,使剧本和具体的饰演者彻底解耦。对应到软件中,导演就像

是一个装配器,它来安排演员表演具体角色

   

   

IoC 的概念:IoC 从字面上看,就是 控制 和 反转

   

到底是什么东西的控制被反转了?对应到前面的实例:

   

"控制" 是指选择刘建明角色扮演者的控制权,而 "反转" 是指这种

控制权,从无间道剧本中移除,转交到导演手中

   

对于软件来说,即 某一个接口的具体实现类的控制权,从调用类

中移除,转交给第三方决定

   

   

因为 IoC 确实不够开门见山,因此业界曾进行了广泛的讨论,最终

软件界的泰斗级人物 Martin Fowler 提出了 DI 的概念用以代替 IoC

   

让调用类对某一接口实现类的依赖关系由第三方(容器 协作类)

注入,以移除调用类对某一接口实现类的依赖

   

"依赖注入" 这个名词显然比 "控制反转" 直接明了、易于理解

   

DI,即 Dependency Injection

   

   

   

   

   

IoC 的注入类型

   

   

从注入方法上看,主要划分为三种类型:

   

· 构造函数注入

   

· 属性注入

   

· 接口注入

   

   

   

1)构造函数注入:

   

通过调用类的构造函数,将接口实现类通过构造函数变量传入

   

如:WuJianDao 即调用类,LiuJianming 即接口,LiuDehua 即接口实现类

   

技术分享

   

技术分享

   

   

   

2)属性注入:

   

通过 Setter 方法完成调用类所需依赖的注入,更加灵活方便

   

如:虽然刘建明是无间道的第一主角,但并非每个场景都需要刘建明出现,

在这种情况下,通过构造函数注入并不妥当,这时可以使用属性注入

   

技术分享

   

技术分享

   

   

   

3)接口注入:

   

将调用类所有依赖注入的方法抽取到一个接口中,调用类通过实现该接口提供相应的注入方法

   

如:ActorArrange 即接口,调用类 WuJianDao 实现该接口

   

技术分享

   

技术分享

   

技术分享

   

   

由于通过接口注入需要额外声明一个接口,这无疑增加了类的数目,

而且效果和属性注入并无本质区别,因此不提倡采用这种方式

   

虽然 WuJianDao 和 LiuDehua 实现了解耦, WuJianDao 无需关注

角色实现类的实例化工作,但这些工作在代码中依然存在,只是转移

Director 类中而已

   

假设某一制片人想改变这一局面,在选择某个剧本后,希望通过一个

媒体海选 第三方中介机构 来选择导演、演员,让他们各司其职,

那剧本、导演、演员就都实现了解耦

   

所谓 媒体海选 第三方中介机构,在程序领域即是一个第三方的容器,

它帮助完成类的初始化与装配工作,让开发者从这些底层实现类的实例

化、依赖关系装配等工作中脱离出来,专注于更有意义的业务逻辑开发

工作,这无疑是一件令人向往的事情,Spring 就是这么一个容器

   

   

   

   

   

IoC 的注入方式

   

   

Spring 作为一个容器,通过 配置文件 注解 描述类和类之间的

依赖关系,自动完成类的初始化和依赖注入的工作

   

下面是对以上实例进行配置的配置文件片段:

   

技术分享

   

   

通过 new XmlBeanFactory("xxx.xml") 等方式即可加载(导入)配置文件

并同时启动 IoC 容器

   

在容器启动时,Spring 根据配置文件的描述信息,自动实例化 Bean 并完成

依赖关系的装配,从容器中即可返回准备就绪的 Bean 实例,后续可直接使用 

   

   

   

Spring 为什么会有这种神奇的力量,仅凭一个简单的配置文件,就能魔法般

地实例化并装配好程序所用的 Bean 呢?

   

这种神奇的力量归功于 Java 语言本身的类反射功能

   

   

   

   

   

   

   

【made by siwuxie095】

IoC概述