IoC 亦称为 “依赖倒置原理”("Dependency Inversion Principle")。差很少全部框架都使用了“倒置注入(Fowler 2004)技巧,这可说是IoC原理的一项应用。SmallTalk,C++, Java 或各类.NET 语言等面向对象程序语言的程序员已使用了这些原理。html
控制反转是Spring框架的核心。程序员
应用控制反转,对象在被建立的时候,由一个调控系统内全部对象的外界实体,将其所依赖的对象的引用,传递给它。也能够说,依赖被注入到对象中。因此,控制反转是,关于一个对象如何获取他所依赖的对象的引用,这个责任的反转。web
IoC就是IoC,不是什么技术,与GoF同样,是一种设计模式。编程
Interface Driven Design接口驱动,接口驱动有不少好处,能够提供不一样灵活的子类实现,增长代码稳定和健壮性等等,可是接口必定是须要实现的,也就是以下语句早晚要执行:AInterface a = new AInterfaceImp(); 这样一来,耦合关系就产生了,如:设计模式
Class A { AInterface a; A() { } aMethod() { a = new AInterfaceImp(); } }
ClassA与AInterfaceImp就是依赖关系,若是想使用AInterface的另一个实现就须要更改代码了。固然咱们能够创建一个Factory来根据条件生成想要的AInterface的具体实现,即:框架
InterfaceImplFactory { AInterface create(Object condition) { if(condition = condA) { return new AInterfaceImpA(); } elseif(condition = condB) { return new AInterfaceImpB(); } else { return new AInterfaceImp(); } } }
表面上是在必定程度上缓解了以上问题,但实质上这种代码耦合并无改变。经过IoC模式能够完全解决这种耦合,它把耦合从代码中移出去,放到统一的XML 文件中,经过一个容器在须要的时候把这个依赖关系造成,即把须要的接口实现注入到须要它的类中,这可能就是“依赖注入”说法的来源了。ide
IOC模式,系统中经过引入实现了IOC模式的IOC容器,便可由IOC容器来管理对象的生命周期、依赖关系等,从而使得应用程序的配置和依赖性规范与实际的应用程序代码分开。其中一个特色就是经过文本的配置文件进行应用程序组件间相互关系的配置,而不用从新修改并编译具体的代码。优化
当前比较知名的IOC容器有:Pico Container、Avalon 、Spring、JBoss、HiveMind、EJB等。url
在上面的几个IOC容器中,轻量级的有Pico Container、Avalon、Spring、HiveMind等,超重量级的有EJB,而半轻半重的有容器有JBoss,Jdon等。spa
能够把IoC模式看作是工厂模式的升华,能够把IoC看做是一个大工厂,只不过这个大工厂里要生成的对象都是在XML文件中给出定义的,而后利用Java 的“反射”编程,根据XML中给出的类名生成相应的对象。从实现来看,IoC是把之前在工厂方法里写死的对象生成代码,改变为由XML文件来定义,也就是把工厂和对象生成这二者独立分隔开来,目的就是提升灵活性和可维护性。
IoC中最基本的Java技术就是“反射”编程。反射又是一个生涩的名词,通俗的说反射就是根据给出的类名(字符串)来生成对象。这种编程方式可让对象在生成时才决定要生成哪种对象。反射的应用是很普遍的,象Hibernate、Spring中都是用“反射”作为最基本的技术手段。
在过去,反射编程方式相对于正常的对象生成方式要慢10几倍,这也许也是当时为何反射技术没有普通应用开来的缘由。但经SUN改良优化后,反射方式生成对象和一般对象生成方式,速度已经相差不大了(但依然有一倍以上的差距)。
IoC最大的好处是什么?由于把对象生成放在了XML里定义,因此当咱们须要换一个实现子类将会变成很简单(通常这样的对象都是实现于某种接口的),只要修改XML就能够了,这样咱们甚至能够实现对象的热插拨(有点象USB接口和SCIS硬盘了)。
IoC最大的缺点是什么?(1)生成一个对象的步骤变复杂了(其实上操做上仍是挺简单的),对于不习惯这种方式的人,会以为有些别扭和不直观。(2)对象生成由于是使用反射编程,在效率上有些损耗。但相对于IoC提升的维护性和灵活性来讲,这点损耗是微不足道的,除非某对象的生成对效率要求特别高。(3)缺乏IDE重构操做的支持,若是在Eclipse要对类更名,那么你还须要去XML文件里手工去改了,这彷佛是全部XML方式的缺憾所在