IOC的理解（转载）

转载自：https://www.zhihu.com/question/23277575/answer/169698662

要了解控制反转( 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。

这里咱们是采用的构造函数传入的方式进行的依赖注入。其实还有另外两种方法：Setter传递和接口传递。这里就很少讲了，核心思路都是同样的，都是为了实现控制反转。

 

看到这里你应该能理解什么控制反转和依赖注入了。那什么是控制反转容器(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的这个特性就很完美的解决了这类问题——由于这个架构要求你在写class的时候须要写相应的Config文件，因此你要初始化好久之前的Service类的时候，前人都已经写好了Config文件，你直接在须要用的地方注入这个Service就能够了。这大大增长了项目的可维护性且下降了开发难度。