Spring控制反转的深入理解

控制反转（inversion of control英文简写是IOC）是一个
重要的面向对象编程的法则来消减计算机程序耦合问题，
也是轻量级的Spring框架的核心。控制反转一般分为两种类型，
依赖注入（Dependency Injection,简称DI）和依赖查找（Dependendy Lookup）
依赖注入应用比较广泛。
早在2004年，Martin folwer就提出了那些方面的控制被反转了，
这个问题，他总结出了是依赖对象的获得被反转了，
基于这个结论，他为控制反转创造了一个更好的名字，依赖注入。
许多非凡的应用（比helloworld更加优美，更加复杂）都是由两个或者更多的类通过
彼此的合作来实现业务逻辑，这使得每个对象都需要与其合作的对象的引用。
IOC也成为依赖倒置原理，（Dependency inversion priniple）.差不多所有框架都使用了
倒置注入的技巧，这可以说是IOC原理的一项应用，SmallTalk C++，java .net等面向对象程序语言的
程序员已经使用了这些原理。
控制反转是sping框架的核心
应用控制反转，对象在被创建的时候，由一个调控系统内所有对象的外界实体将其所依赖的
对象的应用传递给他。
也可以说，依赖被注入到对象中，所以，控制反转是，关于一个对象如何获取他所依赖的对象的引用，
这个责任的反转。






设计模式：IOC可以说是一种全新的设计模式，但是理论和时间成熟相对较晚，并没有包含在GOf中，


Interface Driven Desgin接口驱动，接口驱动有很多好处，可以提供不同的子类实现，增加代码稳定和健壮性，
但是接口一定是需要实现的，也即是如下语句迟早要执行，Alnterface  a = new Ainterfaceimpl();
这样一来，耦合关系就产生了，
Class A
{
   Ainterface a;
   AMethod()
   {
     a = new AInterfaceImp();
   }
}




Class A 与AInterfaceImpl就是依赖关系，如果想使用AInterface的另外一个实现就需要
更改代码了，当然我们可以建立一个Factory来根据条件生成想要的AInterface的具体实现，
InterfaceImplFactory
{
    Alterface crate(Object condition)
    {
     if(condition = condA)
     {
        return new AInterfaceImpA();
     }
     else if(condition = condB)
     {
        return new AInterfaceImpB();
     }
     else
     {
        return new AInterfaceIml();
     }
    }
}
表面上是在一定程度上缓解了以上问题，但实质上这种代码耦合并没有改变，通过
IOc模式可以彻底解决这种模式，它把耦合从代码中移出去，放到了统一的Xml
文件中，通过统一的xml文件中，通过一个容器在需要的时候把这个依赖
关系形成，即把需要的接口实现注入需要他的代码中，
这可能就是依赖注入说法的来源了。


IoC模式，系统中通过引用了实现了IoC模式的IoC容器，即可由IOC容器
来管理对象的生命周期，依赖关系等，
从而使得应用程序的配置和依赖性规与实际的应用程序代码分开。
其中一个特点就是通过文本的配置文件进行应用程序组件间相互关系的配置，
而不用重新修改并编译具体的代码，
当前比较知名IOC容器有：Pico containor ,Avalon,spring,Jboss.hiveMind,Ecjb
在上面的几个容器当中，轻量级的有Pico container，Avalon，Spring，hiveMInd，
超重量级的有EJB，而半轻半重的容器有jboss，jdon


可以把IOc模式看做是工厂模式的升华，可以把IOC看做是一个大工厂，只不过这个大工厂里要生成的对象
都是在xml文件中给定义的，然后利用java的反射编程，根据xml中给出的类名生成相应的对象，
从实现来说，IOC把以前在工厂方法里写死的对象生成代码，改为由xml文件来定义，
也即是把工厂和对象生成这两者独立分割开来，目的就是提高灵活性和可维护性。


IoC中最基本的java技术就是反射编程，反射又是一个生涩的名词，通俗的说反射就是根据
给出的类名来生成相应的对象，这种编程方式可以让对象在生成时才决定要生成哪一个对象，
反射的应用是很广泛的，像hibernate，spring中都是用反射作为最基本的技术手段，


在过去，反射编程方式是相对于正常的对象生成要满10几倍，这也许是当时为什么反射技术
没有普遍应用开来的原因，
但经过sun改良优化后，反射方式生成对象和通常对象生成方式，速度已经相差不多了（但是任然有一杯以上的差距）


优缺点
IOC最大的好处是什么？因为把对象生成放在了xml里定义，所以当我需要换一个实现子类将会变得很简单，
只要修改xml就可以了，这样我们甚至可以实现对象的热插拔
IOC最大的缺点是什么
（1）生成一个对象的步骤变复杂了，对于不习惯这种方式的人，就会觉得有些别扭和不直观
（2）对象生成由于使用反射编程，在效率上有些损耗，但是相对由于IOC提高的维护性和灵活性来说，这点损耗是微不足道的
     除非某对象的生成对效率要求特别高，
 （3） 缺少IDE重构操作的支持，如果再Eclipse中要对类改名，那么你还需要去xml文件里去改了，这似乎是所有xml方式的缺憾所在


实现初探，
IoC关注服务，是如何定义的以及他们应该如何定位他们依赖的其他服务，通常，通过有一个容器
或定位