背景
       流行的、时髦的东西，是特别容易识别的，因为你经常会碰见它们。芙蓉姐姐是这么让我给碰上的，今天想说的IoC也是这么给我碰上的。为了给自己的blog带来点人气，老头子决定也开始走走流行路线。所以，今天我们就来动一动虽然没有芙蓉姐姐那么火，但是也算火的IoC。

Dependency Injection
       IoC，全名叫做Inversion of Control，中文名叫控制反转。我对IoC比较全面的理解，来自于Martin Fowler的这篇文章。Martin Fowler是一位很务实的设计师，他说，IoC，叫做Dependency Injection，控制注入，要更准确一些。所以他的那篇文章的题目就叫Dependency Injection模式。但是，Ioc这个名字好象更火一些，所以，我还是沿用IoC这个名字好了。

       老头子的目标，是用最短的篇幅来介绍IoC，并且告诉各位IoC其实是一个很旧的概念。这是老头子的兴趣所在。

铺垫
       IoC模式，处理的是对象之间的依赖关系，这是为什么Martin先生说Dependency Injection更准确的原因。所以，我们先来看看对象依赖。

       比如有两个对象cA和cB。其中cA依赖于cB。通常我们会看到这样的(伪)代码：
       

class cA...                private cB b;                public cA(){                        b = new cB();                }

       此后，cA对象的方法，就可以直接引用cB的实例b。

       这样的代码并没有啥不妥，但是很明显，cA没有对接口进行依赖，而是依赖于cB的实现，这违反了对接口而不是实现编程的原则。这样做的不好之处在于：如果cB的实现改变了，比如改用了另一个class，cA的代码就需要做出修改。虽然新的cB实现了和老的cB相同的接口，但是替换实现导致了使用者代码的更改，这是不好的行为。也就是说cA被cB粘住了。

咋改
       首先，改成这个样子：
       

interface iB ...        class cB implements iB ...        class cA ...                private iB b;                public cA(){                        b = (iB)(new cB());                }

       这样改了之后，代码好看一些，心情也舒坦一些，但是，跟没改差不多。没有解决根本问题，cA还是要负责创建cB实例，还是得依赖cB。但是，首先iB被分出来了，为下一步改进做好了准备。
       
       iB被分离出来，有一个隐含的好处。就是cA代码的修改，不必担心会使用到特定的cB实现暴露出来的公用方法，因为cA对cB的使用，已经被严格地限定在iB所声明的方法集之内。这样一来，cB的实现，只要实现一个iB接口，其它的可以海阔天空。无需担心由于其它public方法被cA不小心引用而被cA粘住。

解耦
       接口被分离出来之后，剩下的，就是怎么将 new CB() 这个代码从cA里面拿出去。这就是说，怎么样把生成cB实例的任务交给其它对象去做。

       其实问题的关键，就是怎么将iB实例设置到cA.b上面去。这有两种方法：

       一种就是所谓的IoC。它通过cA对象的某个方法将一个作为外部参数传入进来的iB实例赋给cA.b。根据这个方法的不同，人们把IoC又分为三种类型，虽然在我看来它们是一回事。

       还有一种，叫做Service Locator。就是把生成实例的任务，委托给一个周知的对象。把对其它对象的依赖，变成对该对象的依赖。这样的话，只要该对象能稳定，问题就不大了。

IoC
       先说IoC的三种方法：

       1。构造子注入，也叫type 3 IoC。实际上就是用构造函数来给cA.b赋值：
       

class cA ...                public cA(iB ib){                        b = ib;                }

       2。设值方法，也叫type 2 IoC。用一个set×××方法来给cA.b赋值：
       

class cA ...                public void setiB(iB ib){                        b = ib;                }

       3。接口注入，也叫type 1 IoC。cA开发一个接口，让框架通过该接口来给cA.b赋值：
       

public interface InjectiB{                void injectiB(iB ib);        }        class cA implements InjectiB ...                public void injectiB(iB ib){                        b = ib;                }

       这三种方式，形式有所不同，实质没啥区别。总之，都是提供接口让IoC容器来调用，并通过这些暴露的接口来完成依赖的注入。因为这个赋值方法都是被IoC容器或外部应用调用，控制权从cA转移到外部框架去了。这就是控制反转名称的由来。

       使用IoC之后，应用代码大致如下：
       

......                iB b = (iB)(new cB());                cA a = new cA(b);                或者                cA a = new cA();                a.setiB(b);                或者                cA a = new cA();                a.injectiB(b);                ......

       做得好的IoC容器，可以将 new cB() 和 new cA() 的过程全部通过配置和容器来自动完成。

Service Locator
       相对来说，Service Locator更简单直观一些，它的代码形如：
       

class cA ...                private iB b = serviceLocator.getInstance("iB");

       其中，serviceLocator可以实现为一个Singleton，或者作为一个静态成员传递给cA。因为它是周知的对象，这不是问题。

事实上
       在我看来，IoC和ServiceLocator模式，并没有太大的差别。它们都将对象的实例化交给框架或第三方去完成，而当使用者需要对象的时候，对象已经准备好。差别只在于，对于IoC模式来说，对象赋值是由外部代码完成的，使用者处于被动地位；而对于ServiceLocator来说，对象赋值是使用者主动请求完成的，它处于主动地位。

       对于这两种模式的比较，意义并不太大。到底使用哪一个，取决于个人的偏好。老头子在这里也就不多说什么了。

旧东西
       我们只要回忆一下COM框架，就会知道IoC和ServiceLocator在那里其实都是旧东西。当微软把Automation再添加到COM架构中去的时候，我们不能不感叹，COM是个好东西。憎恨微软当然没有问题，但依我看，对于微软，不服恐怕也是不行的。

       至少，产品中处处体现出先进的设计理念的微软，没有象Java社群这样喜欢鼓噪新的概念。微软能够赢得最终用户的心，那也不是没有理由的。

预告
       左手剑的下一击，我想讲讲同样火的AOP是个什么东西，以及，为什么说它也是个旧东西。