Ioc:从自助和回转火锅看控制反转

       Ioc (Inversion of Control)，意为控制反转，是Spring框架的核心。但是它不仅仅是一种技术，更多的角色扮演着一种设计思想，也有人把它当做一种设计模式来对待。我查看了很多前辈大牛的博客，再加上自己的ITOO中使用的一点经验，写一下自己对Ioc的理解。

     个人觉得Ioc的前世今生一切玄奥都在“控制反转”这四个字上。理解好”控制“和”反转“也就是了解Ioc这一设计思想了。首先，我举个小例子来说明下，方便大家理解。

场景一：吃自助。
      A：顾客
      B：同伴
      C：服务员


      A：“我想吃烤鸭”。
      C：“......”（微笑不语）。
      B：“想吃烤鸭，自己去拿”。   
      
     自助相信大家都不陌生，吃自助最大的特点就是“自助”，也就是自取，想吃什么，自己去拿什么。不去拿，就吃不着。


场景二：吃回转火锅。


      A：顾客
      B：同伴
      C：服务员


      A：“我想吃烤鸭”。
      C：“......”（微笑不语）。
      B：“等会儿，一会就转过来了！”。 

     通过这两个例子，我结合“控制”和“反转”讲一下自己的理解。这两个场景包含了三个特性“烤鸭”“顾客”“是否动脚”，分别代表“依赖的对象”“main程序”“是否实例化”。场景一是没有采用Ioc设计思想的写法，既顾客想吃烤鸭，得自己亲自去取，不取就吃不到。这个亲自去取的过程就可以理解为”控制“（main程序员能不能使用到依赖的对象，完全取决于是否实例化，也被称为正转）。而场景二就不同了，顾客想吃什么，不用去取，等烤鸭回转到面前，就可以吃了。既顾客亲自去取的“控制”被回转的机制取代了。换句话说，顾客能不能吃到烤鸭的控制权不在自己身上了（原来需要动动脚就可以了，现在需要等烤鸭回转到面前才可以），这就是”控制反转“。

      拿经典的三层来举例，U层调用B层的方法，首先需要在U层实例化B层，才可以调用方法，这是传统的方式。虽然功能能实现，但是问题也留了下来，1.在U层实例化B层的对象，导致U层大大依赖了B层，增加了两者的耦合度。2.在U层实例化的对象是有生命周期的，如何销毁和何时销毁是个问题。

      但是采用Ioc思想就不同了，同样U层调用B层方法，Ioc的思想是将实例化的过程（暂时这样理解）放到一个容器里，当U层调用B层的对象方法时，容器会适时地给U层提供这个对象方法。这样的好处是U层不用去实例化B层就可以使用B层对象的方法，更不用说什么去维护B层对象的生命周期了。

      Ioc (控制反转)其实就是脱胎于传统的调用方法。传统里是由主程序去控制对象的是否实例化，但是Ioc却剥夺了主程序这个权利，由容器去给主程序提供实例化的对象。