文章目录
引言
在学习Spring 的过程中我们经常会接触到IOC（控制反转），大家也知道IOC是Sping 的重要核心之一，那么如何理解它呢，它又是产生什么作用呢？以下是我经过查阅资料后的总结理解，供大家参考。
IOC
依赖倒置原则
要了解IOC，我们有必要先了解软件设计的一个重要思想：
依赖倒置原则
什么是依赖倒置原则
假设我们设计一辆汽车：先设计轮子，然后根据轮子大小设计底盘，接着根据底盘设计车身，最后根据车身设计好整个汽车。这里就出现了一个“依赖”关系：汽车依赖车身，车身依赖底盘，底盘依赖轮子。
这样的设计看起来没问题，但是可维护性却很低。假设设计完工之后，上司却突然说根据市场需求的变动，要我们把车子的轮子设计都改大一码。这下我们就蛋疼了：因为我们是根据轮子的尺寸设计的底盘，轮子的尺寸一改，底盘的设计就得修改；同样因为我们是根据底盘设计的车身，那么车身也得改，同理汽车设计也得改——整个设计几乎都得改！
我们现在换一种思路。我们先设计汽车的大概样子，然后根据汽车的样子来设计车身，根据车身来设计底盘，最后根据底盘来设计轮子。这时候，依赖关系就倒置过来了：轮子依赖底盘， 底盘依赖车身， 车身依赖汽车。
这就是依赖倒置原则——把原本的高层建筑依赖底层建筑“倒置”过来，变成底层建筑依赖高层建筑。高层建筑决定需要什么，底层去实现这样的需求，但是高层并不用管底层是怎么实现的。这样就不会出现前面的“牵一发动全身”的情况。
理解IOC
控制反转（Inversion of Control）
就是依赖倒置原则的一种代码设计的思路。具体采用的方法就是所谓的
依赖注入（Dependency Injection）
。赖注入（DI）和控制反转（IOC）是从不同的角度的描述的同一件事情，指就是
通过引入IOC容器，利用依赖关系注入的方式，实现对象之间的解耦
。
其实这些概念初次接触都会感到云里雾里的。说穿了，这几种概念的关系大概如下：
为了理解这几个概念，我们还是用上面汽车的例子。只不过这次换成代码。我们先定义四个Class，车，车身，底盘，轮胎。然后初始化这辆车，最后跑这辆车。代码结构如下：
未实现控制反转
这样，就相当于上面第一个例子，上层建筑依赖下层建筑——每一个类的构造函数都直接调用了底层代码的构造函数。假设我们需要改动一下轮胎（Tire）类，把它的尺寸变成动态的，而不是一直都是30。我们需要这样改：
由于我们修改了轮胎的定义，为了让整个程序正常运行，我们需要做以下改动：
由此我们可以看到，仅仅是为了修改轮胎的构造函数，这种设计却需要
修改整个上层所有类的构造函数
！在软件工程中，
这样的设计几乎是不可维护的
——在实际工程项目中，有的类可能会是几千个类的底层，如果每次修改这个类，我们都要修改所有以它作为依赖的类，那软件的维护成本就太高了。
所以我们需要进行
控制反转
（IoC），及上层控制下层，而不是下层控制着上层。我们用依赖注入（Dependency Injection）这种方式来实现控制反转。
所谓依赖注入，就是把底层类作为参数传入上层类，实现上层类对下层类的“控制
”。这里我们用
构造方法传递的依赖注入方式
重新写车类的定义：
实现控制反转
这里我们再把轮胎尺寸变成动态的，同样为了让整个系统顺利运行，我们需要做如下修改：
看到没？这里**我只需要修改轮胎类就行了，不用修改其他任何上层类。
这显然是更容易维护的代码。不仅如此，在实际的工程中，这种设计模式还有利于
不同组的协同合作和单元测试：**比如开发这四个类的分别是四个不同的组，那么只要定义好了接口，四个不同的组可以同时进行开发而不相互受限制；而对于单元测试，如果我们要写Car类的单元测试，就只需要Mock一下Framework类传入Car就行了，而不用把Framework, Bottom, Tire全部new一遍再来构造Car。
这里我们是采用的
构造函数传入
的方式进行的依赖注入。其实还有另外两种方法：
Setter传递
和
接口传递
。这里就不多讲了，核心思路都是一样的，都是为了实现
控制反转
。
理解IOC容器
什么是**控制反转容器(IoC Container)**呢？其实上面的例子中，对车类进行初始化的那段代码发生的地方，就是控制反转容器。
显然你也应该观察到了，因为采用了依赖注入，在初始化的过程中就不可避免的会写大量的new。这里
IoC
容器就解决了这个问题。
这个容器可以自动对你的代码进行初始化，你只需要维护一个Configuration（可以是xml可以是一段代码），而不用每次初始化一辆车都要亲手去写那一大段初始化的代码
。这是引入IoC Container的第一个好处。
IoC Container的第二个好处是：**我们在创建实例的时候不需要了解其中的细节。**在上面的例子中，我们自己手动创建一个车instance时候，是从底层往上层new的：
这个过程中，我们需要了解整个Car/Framework/Bottom/Tire类构造函数是怎么定义的，才能一步一步new/注入。
而IoC Container在进行这个工作的时候是反过来的，它先从最上层开始往下找依赖关系，到达最底层之后再往上一步一步new（有点像深度优先遍历）：
这里IoC Container可以直接隐藏具体的创建实例的细节，在我们来看它就像一个工厂：
我们就像是工厂的客户。我们只需要向工厂请求一个Car实例，然后它就给我们按照Config创建了一个Car实例。我们完全不用管这个Car实例是怎么一步一步被创建出来。
实际项目中，有的Service Class可能是十年前写的，有几百个类作为它的底层。假设我们新写的一个API需要实例化这个Service，我们总不可能回头去搞清楚这几百个类的构造函数吧？IoC Container的这个特性就很完美的解决了这类问题，大大增加了项目的可维护性且降低了开发难度。
IOC和DI的关系
DI—Dependency Injection，即**“依赖注入”：是组件之间依赖关系由容器在运行期决定，形象的说，即由容器动态的将某个依赖关系注入到组件之中**。通过依赖注入机制，我们只需要通过简单的配置，而无需任何代码就可指定目标需要的资源，完成自身的业务逻辑，而不需要关心具体的资源来自何处，由谁实现。
理解DI的关键是：“谁依赖谁，为什么需要依赖，谁注入谁，注入了什么”，那我们来深入分析一下：
●**谁依赖于谁：**当然是应用程序依赖于IOC容器；
●**为什么需要依赖：**应用程序需要IoC容器来提供对象需要的外部资源；
●**谁注入谁：**很明显是IoC容器注入应用程序某个对象，应用程序依赖的对象；
**●注入了什么：**就是注入某个对象所需要的外部资源（包括对象、资源、常量数据）。
IOC和DI由什么关系呢？其实它们是同一个概念的不同角度描述，由于控制反转概念比较含糊（可能只是理解为容器控制对象这一个层面，很难让人想到谁来维护对象关系），所以
2004年大师级人物Martin Fowler又给出了一个新的名字：“依赖注入”，相对IoC 而言，“依赖注入”明确描述了“被注入对象依赖IoC容器配置依赖对象”。
涉及设计模式
工厂模式
Spring使用工厂模式可以通过 BeanFactory 或 ApplicationContext 创建 bean 对象。
两者对比：
- BeanFactory ：延迟注入(使用到某个 bean 的时候才会注入),相比于ApplicationContext 来说会占用更少的内存，程序启动速度更快。
- ApplicationContext ：容器启动的时候，不管你用没用到，一次性创建所有 bean 。BeanFactory 仅提供了最基本的依赖注入支持，ApplicationContext 扩展了 BeanFactory ,除了有BeanFactory的功能还有额外更多功能，所以一般开发人员使用ApplicationContext会更多。
ApplicationContext的三个实现类：
ClassPathXmlApplication：把上下文文件当成类路径资源。
FileSystemXmlApplication：从文件系统中的 XML 文件载入上下文定义信息。
XmlWebApplicationContext：从Web系统中的XML文件载入上下文定义信息。
单例模式
Spring 中 bean 的默认作用域就是 singleton(单例)的。
策略模式
在策略模式（Strategy Pattern）中，一个类的行为或其算法可以在运行时更改。这种类型的设计模式属于行为型模式。在策略模式中，我们创建表示各种策略的对象和一个行为随着策略对象改变而改变的 context 对象。策略对象改变 context 对象的执行算法。策略模式实际就是一堆算法族的封装。
Spring中策略模式的应用
当bean需要访问资源配置文件时，Spring有两种方式
- 代码中获取Rescource实例
- 依赖注入
第一种方式需要获取rescource资源的位置，代码中耦合性太高，而今我们一直使用注解，依赖注入的方式去获取。这样的话就无需修改程序，只改配置文件即可。
装饰模式
通过使用修饰模式，可以在运行时扩充一个类的功能。原理是：增加一个修饰类包裹原来的类，包裹的方式一般是通过在将原来的对象作为修饰类的构造函数的参数。装饰类实现新的功能，但是，在不需要用到新功能的地方，它可以直接调用原来的类中的方法。修饰类必须和原来的类有相同的接口。
Spring中类中带有Wrapper的都是包装类
总结
在Java开发中，IOC意味着将你设计好的对象交给容器控制，而不是传统的在你的对象内部直接控制。理解好IOC的关键是要明确“谁控制谁，控制什么，为何是反转（有反转就应该有正转了），哪些方面反转了”：
●**谁控制谁，控制什么：**传统Java SE程序设计，我们直接在对象内部通过new进行创建对象，是程序主动去创建依赖对象；而IOC是有专门一个容器来创建这些对象，即由IOC容器来控制对象的创建以及外部资源获取（不只是对象包括比如文件等）。
●**为何是反转，哪些方面反转了：**有反转就有正转，传统应用程序是由我们自己在对象中主动控制去直接获取依赖对象，也就是正转；而反转则是由容器来帮忙创建及注入依赖对象：由容器帮我们查找及注入依赖对象，对象只是被动的接受依赖对象，所以是反转，依赖对象的获取被反转了。
IOC好处
- 降低了程序的耦合性
- 集中了资源的管理，实现了资源的可配置和易管理
- 便于测试
参考文章