spring中为什么要使用IOC

开篇前言

 在前面的博文中，小编主要简单的介绍了spring的入门知识，随着学习的深入，我们知道spring最核心的两大技术，IOC和AOP，这两个技术也是spring最耀眼的地方，在后续的博文中小编将隆重介绍IOC和AOP，今天这篇博文，小编先简单的介绍一下，IOC是什么？在spring中为什么要使用IOC？IOC的优缺点以及IOC的应用。 IOC是什么？ 控制反转（Inversion of Control，英文缩写为IoC）是一个重要的面向对象编程的法则来削减计算机程序的耦合问题，也是轻量级的Spring框架的核心。 控制反转一般分为两种类型，依赖注入（Dependency Injection，简称DI）和依赖查找（Dependency Lookup）。依赖注入应用比较广泛。控制反转，包含两个方面的内容，一个是控制，另一个是反转，在程序中被调用类的选择控制权从调用她的类中移除，转交给第三方裁决，这个第三方指的就是spring的容器，IOC另解，依赖注入，调用类对被调用类的依赖关系由第三方注入，以移除调用类对被调用类的引用。其实小编觉得IOC这个概念还是比较晦涩难懂的，不容易让人望文生义，不过IOC确实包含了很多的内在东西，涉及到代码解耦，设计模式，代码优化等等，接下来小编就通过一个简单的demo，来帮助小伙伴们理解IOC的概念。 从西游记到IOC 西游记，家喻户晓，老少皆宜，曲折的故事，动情的演绎，给小编的童年带来无数的欢乐和惊喜，在西游记中有不少这样的场景，每每唐僧被抓的时候，六小龄童扮演的孙悟空来到妖怪的洞口，妖怪总是问，来者何人，孙悟空回答：你孙爷爷在此，我们不妨通过一个Java类为这个场景进行编剧，并且伴随古典名著来理解IOC的概念，是不是别有一番风味。 通过演员安排剧本，java代码如下所示：

public class XiYouJi {      public void monsterAsk(){           //演员直接侵入剧本            LiuXiaoLingTong  lxlt = new LiuXiaoLingTong ()；        swk .responseAsk("你孙爷爷！");       }    }   

 通过上面的代码部分，我们发现，作为具体角色饰演者的六小龄童直接倾入到剧本中，这样，使得剧本和演员直接耦合在一起。  一个聪慧的编剧在创作的时候应该围绕故事的角色进行，而不应该考虑这个角色的具体扮演者，只有这样，孙悟空的角色任选可以从众多演员中自由的选择，而非绑定在六小龄童一个人身上，通过分析，我们知道需要用主人公孙悟空定义一个接口，代码如下所示：

public class  XiYouJi {    public void monsterAsk()    {       //引入孙悟空角色接口        SunWuKong swk = new  SunWuKong();        //通过接口开展剧情        swk .responseAsk("你孙爷爷！");    }    }    

 我们引入了剧本的角色，也就是孙悟空，剧本的情节通过角色展开，在拍摄时角色由演员饰演，通过代码我们可以知道 XiYouJi同时依赖于SunWuKong接口和LiuXiaoLingTong类，并没有达到我们所期望的剧本仅依赖于角色的目的。但是角色最终必须通过具体的演员才能完成拍摄，如何让LiuXiaoLingTong和剧本无关而又能完成SunWuKong的具体动作呢？当然是在西游记投拍时，导演将LiuXiaoLingTong安排在SunWuKong的角色上，导演将剧本、角色、饰演者装配起来。  通过引入导演，使剧本和具体饰演者解耦了。对应到软件中，导演像是一个装配器，安排演员表演具体的角色。 现在我们可以反过来讲解IoC的概念了。IoC（Inverse of Control）的字面意思是控制反转，它包括两个内容： 即控制和反转。 那到底是什么东西的“控制”被“反转”了呢？对应到前面的例子，“控制”是指选择GeLi角色扮演者的控制权；“反转”是指这种控制权从《墨攻》剧本中移除，转交到导演的手中。对于软件来说，即是某一接口具体实现类的选择控制权从调用类中移除，转交给第三方决定。  因为IoC确实不够开门见山，因此业界曾进行了广泛的讨论，最终软件界的泰斗级人物Martin Fowler提出了DI（依赖注入：Dependency Injection）的概念用以代替IoC，即让调用类对某一接口实现类的依赖关系由第三方（容器或协作类）注入，以移除调用类对某一接口实现类的依赖。“依赖注入”这个名词显然比“控制反转”直接明了、易于理解。 那么IOC有着怎么样的优点和缺点呢？请看如下对比 IOC的优点和缺点 IOC的优点     a、实现组件之间的解耦，提高程序的灵活性和可维护性。 IOC的缺点:     a、创建对象的步骤变复杂了，不直观，当然这是对不习惯这种方式的人来说的。     b、因为使用反射来创建对象，所以在效率上会有些损耗。但相对于程序的灵活性和可维护性来说，这点损耗是微不足道的。     c、缺少IDE重构的支持，如果修改了类名，还需到XML文件中手动修改，这似乎是所有XML方式的缺憾所在。 IOC的应用： IOC模式将耦合代码从程序中移出，放到统一的XML文件中管理。由IOC容器通过配置文件来管理对象的生命周期、依赖关系等，这样就不用重新修改并编译具体的代码，从而实现组件之间的解耦。