Spring中的IOC

时间：2014-07-30 17:24:44 阅读：266 评论：0 收藏：0 [点我收藏+]

标签：style blog http 使用 os io 2014 art

在学习spring的时候，最常听到的词应该就是IOC和AOP了，下面，我从我的角度再次理解一下Spring里的IOC和AOP.

IOC简介

IoC(InversionofControl)：IoC就是应用本身不依赖对象的创建和维护而是交给外部容器(这里为spring),这要就把应用和对象之间解耦,控制权交给了外部容器。即Don‘tcallme,I‘llcallyou！所以IoC也称DI(依赖注入)对象的创建和维护依赖于外部容器.

IOC详解

关于IOC的博客有很多，我们可以从这篇博客中了解一下：

深入浅出Spring（二）IoC详解

简单理解IOC

我们从文章中发现，其实ioc所做的一件事情就是把A和B的强耦合关系，变成A依赖于B的接口的关系，但具体A要实现B接口中哪一种B类型，由C来决定，以达到解耦，通俗来讲，我们在家到饭点的时候就会说“我要吃饭”，我这里代表的是A，饭代表的是B的接口，但是具体是要吃什么饭，那就由你的妈妈在决定，你妈妈给你在碗里放了米饭（B），你就要吃米饭，当然，今天你妈妈开心，也可以给你碗里放一个鸡腿，这个决定权在你的妈妈，也就是我们常说的把控制权交给第三方。一次来达到我（A）和米饭（B）的解耦。

DI与IOC 的关系

我们可能会经常听到另一个词：DI,这里，简单的做一下讲解：

因为IOC确实不够开门见山，因此业界曾进行了广泛的讨论，最终软件界的泰斗级人物MartinFowIer提出了DI（依注入：Dependency Injection)的概念用以代替loc,即让调用类对某一接口实现类的依赖关系由第三方（容器或协作类）注入，以移除调用类对某一接口实现类的依赖。“依賴注入”这个名词显然比“控制反转”直接明了、易于理解。

所以，我认为IOC和DI描述的是一件事情，只是从不同的角度来描述：

IOC控制反转：说的是创建对象实例的控制权从代码控制剥离到IOC容器控制，实际上就是我们现在说的第三方，侧重于原理。

DI依赖注入：说的是创建对象实例时，为这个对象注入属性值或其它对象实例，侧重于实现。

说到DI，可能就会有出现这样一个问题，既然DI侧重实现，那么他是怎么实现的呢？也就是怎么注入的呢？下面我们

几种注入方式：

简单说一下几种注入方式：

第一种：构造函数注入（这里我们直接沿用上面的例子）：

       publicclass Team { 
         privateLeader leader；
         publicTeam(Leader leader){
                   this.leader=leader;
}
             public void firstMetting(){ 
                 leader.introduce(); 
             } 
         }   
在Boss出的代码为：
public class Boss {  
   public void direct(){ 
       Leader leader = new Li(); 
       Team team = new Team(leader); 
       team.firstMetting(); 
}

第二种：属性注入：

有时,我们会发现,虽然小李在这个team里要发言，，但并非每次都要发言，在这种情况下通过构造函数注入并不妥当，这时可以考虑使用属性注入。属性注入可以有选择地通过setter方法完成调用类所需依赖的注入，更加灵活方便；

public class Team { 
         privateLeader leader；
         publicvoid SetLeader (Leader leader){
                   this.leader=leader;
}
             public void firstMetting(){ 
                 leader.introduce(); 
             } 
         }   
在Boss出的代码为：
public class Boss { 
   public void direct(){ 
       Leader leader = new Li(); 
       Team team = new Team(); 
                   Team.setLeader(leader);
       team.firstMetting(); 
}

和通过构造函数注入不同，在实例化Team时，并未指定任何发言人，而是在实例化Team后，在需要小李出场时，才调用其setLeader方法注入扮演者。按照类似的方式，这样，我们就可以在不同的场合，注入相应的发言人了。

第三种：接口注入：

定义接口:
Public interface teamInject{
         voidinjectLeader(Leader leader);
}
public class Team implements teamInject { 
         privateLeader leader；
         publicvoid injectLeader (Leader leader){
                   this.leader=leader;
}
             public void firstMetting(){ 
                 leader.introduce(); 
             } 
         }   
在Boss出的代码为：
public class Boss { 
   public void direct(){ 
       Leader leader = new Li(); 
       Team team = new Team(); 
                   Team.setLeader(leader);
       team.firstMetting(); 
}

由于通过接口注入需要额外声明一个接口，增加了类的数目，而且它的效果和属性注

入并无本质区别，因此我们不提倡采用这种方式。