Spring-控制反转IOC
# Spring-控制反转IOC
一句话总结
采用依赖倒置的原则，实现了控制反转的思想，通过依赖注入的方法，完成了 IOC 容器的创建
参考知乎回答：Spring IoC有什么好处呢？
# 依赖倒置原则
要了解控制反转( Inversion of Control )，我觉得有必要先了解软件设计的一个重要思想：依赖倒置原则（Dependency Inversion Principle ）。
什么是依赖倒置原则？假设我们设计一辆汽车：先设计轮子，然后根据轮子大小设计底盘，接着根据底盘设计车身，最后根据车身设计好整个汽车。这里就出现了一个“依赖”关系：汽车依赖车身，车身依赖底盘，底盘依赖轮子。
这样的设计看起来没问题，但是可维护性却很低。假设设计完工之后，上司却突然说根据市场需求的变动，要我们把车子的轮子设计都改大一码。这下我们就蛋疼了：因为我们是根据轮子的尺寸设计的底盘，轮子的尺寸一改，底盘的设计就得修改；同样因为我们是根据底盘设计的车身，那么车身也得改，同理汽车设计也得改——整个设计几乎都得改！
我们现在换一种思路。我们先设计汽车的大概样子，然后根据汽车的样子来设计车身，根据车身来设计底盘，最后根据底盘来设计轮子。这时候，依赖关系就倒置过来了：轮子依赖底盘， 底盘依赖车身， 车身依赖汽车。
这时候，上司再说要改动轮子的设计，我们就只需要改动轮子的设计，而不需要动底盘，车身，汽车的设计了。
这就是依赖倒置原则——把原本的高层建筑依赖底层建筑“倒置”过来，变成底层建筑依赖高层建筑。高层建筑决定需要什么，底层去实现这样的需求，但是高层并不用管底层是怎么实现的。这样就不会出现前面的“牵一发动全身”的情况。
# 控制反转
控制反转（Inversion of Control） 就是依赖倒置原则的一种代码设计的思路。具体采用的方法就是所谓的依赖注入（Dependency Injection）。这几种概念的关系大概如下：
为了理解这几个概念，我们还是用上面汽车的例子。只不过这次换成代码。我们先定义四个 Class：车，车身，底盘，轮胎。然后初始化这辆车，最后跑这辆车。代码结构如下：
这样，就相当于上面第一个例子，上层建筑依赖下层建筑——每一个类的构造函数都直接调用了底层代码的构造函数。假设我们需要改动一下轮胎（Tire）类，把它的尺寸变成动态的，而不是一直都是30。我们需要这样改：
由于我们修改了轮胎的定义，为了让整个程序正常运行，我们需要做以下改动：
由此我们可以看到，仅仅是为了修改轮胎的构造函数，这种设计却需要修改整个上层所有类的构造函数！在软件工程中，这样的设计几乎是不可维护的——在实际工程项目中，有的类可能会是几千个类的底层，如果每次修改这个类，我们都要修改所有以它作为依赖的类，那软件的维护成本就太高了。
所以我们需要进行控制反转（IoC），即上层控制下层，而不是下层控制着上层。我们用依赖注入（Dependency Injection）这种方式来实现控制反转。所谓依赖注入，就是把底层类作为参数传入上层类，实现上层类对下层类的“控制”。这里我们用构造方法传递的依赖注入方式重新写车类的定义：
这里我们再把轮胎尺寸变成动态的，同样为了让整个系统顺利运行，我们需要做如下修改：
这里我只需要修改轮胎类就行了，不用修改其他任何上层类。这显然是更容易维护的代码。不仅如此，在实际的工程中，这种设计模式还有利于不同组的协同合作和单元测试：比如开发这四个类的分别是四个不同的组，那么只要定义好了接口，四个不同的组可以同时进行开发而不相互受限制；而对于单元测试，如果我们要写 Car 类的单元测试，就只需要 Mock 一下 Framework 类传入 Car 就行了，而不用把Framework, Bottom, Tire 全部 new 一遍再来构造 Car。
# 控制反转容器
IoC Container 的第一个好处是：因为采用了依赖注入，在初始化的过程中就不可避免的会写大量的 new。这里 IoC 容器就解决了这个问题。这个容器可以自动对你的代码进行初始化，你只需要维护一个 Configuration（可以是xml可以是一段代码），而不用每次初始化一辆车都要亲手去写那一大段初始化的代码。
IoC Container 的第二个好处是：**我们在创建实例的时候不需要了解其中的细节。**在上面的例子中，我们自己手动创建一个车instance时候，是从底层往上层new的：
这个过程中，我们需要了解整个 Car/Framework/Bottom/Tire 类构造函数是怎么定义的，才能一步一步注入。
而 IoC Container 在进行这个工作的时候是反过来的，它先从最上层开始往下找依赖关系，到达最底层之后再往上一步一步 new（有点像深度优先遍历）：
这里 IoC Container 可以直接隐藏具体的创建实例的细节，在我们来看它就像一个工厂：
我们就像是工厂的客户。我们只需要向工厂请求一个 Car 实例，然后它就给我们按照 Config 创建了一个 Car 实例。我们完全不用管这个 Car 实例是怎么一步一步被创建出来。
实际项目中，有的 Service Class 可能是十年前写的，有几百个类作为它的底层。假设我们新写的一个 API 需要实例化这个 Service，我们总不可能回头去搞清楚这几百个类的构造函数吧？IoC Container 的这个特性就很完美的解决了这类问题——因为这个架构要求你在写 class 的时候需要写相应的 Config 文件，所以你要初始化很久以前的 Service 类的时候，前人都已经写好了 Config 文件，你直接在需要用的地方注入这个 Service 就可以了。这大大增加了项目的可维护性且降低了开发难度。
# 依赖注入
DI（dependency Inject，依赖注入）是实现控制反转的一种设计模式，依赖注入就是实例变量传入到一个对象中去。
IOC是一种思想，DI是一种具体的技术手段。
IoC是站在对象的角度上，对象的实例化以及管理从程序员手里交给了IoC容器。DI是站在容器的角度上，把对象的依赖的其他对象注入到容器中。
主要有三种注入方式：
构造器注入：
被注入对象可以在它的构造方法中声明依赖对象的参数列表，让外部知道它需要哪些依赖对象。然后，IoC会检查被注入对象的构造方法，取得它所需要的依赖对象列表，进而为其注入相应的对象。构造方法注入比较直观，对象被构造完后，即进入就绪状态，可以马上使用。
setter方法注入：
通过setter方法，可以更改相应的对象属性。所以，当前对象只要为其依赖对象所对应的属性添加setter方法，就可以通过setter方法将相应的依赖对象设置到被注入对象中。setter方法注入虽不像构造方法注入那样，让对象构造完成后即可使用，但相对来说更宽松一些。
接口注入：
被注入对象如果想要IoC为其注入依赖对象，就必须实现某个接口。这个接口提供一个方法，用来为其注入依赖对象。IoC最终通过这些接口来了解应该为被注入对象注入什么依赖对象。
# 总结
我的理解，IOC可以概括为四部分：采用依赖倒置的原则，实现了控制反转的思想，通过依赖注入的方法，完成了IOC容器的创建。
⭐ 依赖倒置原则
IOC是一种解耦的设计思想，采用依赖倒置原则，把原本的高层建筑依赖底层建筑“倒置”过来，变成底层建筑依赖高层建筑；
采用高层建筑依赖底层建筑的思想进行造车，就是先制作轮胎，根据轮胎制造地盘，根据地盘制作车身，根据车身制造汽车，如果对轮胎进行修改的话，则需要对地盘、车身、汽车依次进行修改，牵一发动全身。
采用底层建筑依赖高层建筑的思想进行造车，就是先规划汽车、根据汽车规划车身，根据车身规划地盘，根据地盘规划轮胎，如果对轮胎进行修改的话，则无需对汽车、车身、地盘进行修改。
那如果我要修改汽车怎么办？车身、底盘、轮胎是不是都要改？这就要看如何修改车身了，我们要尽可能的不破坏原有配置的兼容性，尽量只做扩展而不修改。
⭐ 控制反转思想
通过IOC，我们将手动创建对象的控制器交由Spring框架来管理，当我想要一个Car实例时，Spring框架会自动创建Car实例交给我，而我完全不用管这个实例时如何一步步被创建出来的。IOC容器的底层实现就是通过工厂模式反射创建对象，它如同工厂一样为我们造出所需的一切实例。
⭐依赖注入
采用构造器注入或setter方法注入或接口注入的方法，往正在实例化的对象内注入他所依赖的对象。
⭐ IOC容器
IOC容器，就是用于存放对象的Map，IOC创建出来的所有对象都存储到Map当中，当我们需要某个对象时可以从这个Map中获取。
通常所说的 Bean 就是IOC容器所管理的对象，通过配置 XML 或注解来定义 Bean 对象