ioc和di的关系

        刚进入spring的时候，看见这两个词一阵迷茫，控制反转不知道转的是啥，依赖注入也不知道注入的啥。有的人说这两个是一个，有的说di是ioc的实现，我就说说我的理解。

        从getter和setter开始

        从开始学习mvc设计模式，或者是jsp异或是框架，必然会有JavaBean或者其他类似的概念出现。getter和setter就是JavaBean中的重要部分，通过这种方式，不需要考虑依赖对象的创建过程，省去了内部出现new的情况，大大降低了耦合性。但是这种方式只是把底层的耦合性降低，依赖关系还是需要高层的Java程序将依赖对象注入。

        所以不满足的程序员提出了问题，耦合性的降低是否还可以更进一步？

        所以就有了ioc和di的出现，很多框架甚至是所有的框架，都实现了ioc的功能 ，spring也不例外而ioc和di的概念也紧随其后，做为spring的功能的解释。

之前一直错误的以为ioc和di是因为spring才出现的，实则不然，spring是一个良好的嵌入这两个功能的框架，但这两个功能或者说是思想，是因为需求才出现的，而框架是这些优良思想的具体实现和整合。

        ioc的出现

        ioc，inverse of control，控制反转。直接理解一下就是，将耦合关系的控制权力反转，或者说是将依赖注入的权力反转。本来依赖注入是谁控制的，Java类自己new对象。后来是高层对象创建后，用setter方法注入，而且还增加了高层对象对于依赖对象的维护。ioc的出现就极大的解决了这些问题，ioc容器接管了依赖注入的权力，全部由ioc容器来控制。这就是控制反转，由应用程序控制反转为ioc容器控制。其实，ioc的概念，已经不是仅仅程序的反转控制了，而是完全的外部资源控制。

        不过，还有一些问题。

        ioc的反转控制没错，但它还内涵了依赖注入的意思。可是字面上并没有体现，所以Martin Fowler 在2004年初的一篇论文中首次提出了di这一名词。

        di的出现

        di，dependency injection，依赖注入。di就是在指ioc容器内实现的将依赖对象注入的概念。而依赖注入这一概念的实现，必然也内涵着权力控制的条件，否则spring没有基础的控制权力，如何注入。

        总结

        ioc和di一个意思其实并没有错。ioc作为率先提出的概念内涵着一部分概念，不直接，有些难受，就提出了di。很有意思的是，他们都内涵着对方的意思。

        当然如果你要是强制认为，ioc就是容器，di就是注入这一行为，那么di确实就是ioc的具体功能的实现。而ioc则是di发挥的平台和空间。

        所以说，ioc和di即是相辅相成的搭档，又是殊途同归的双胞胎。最重要的是，他们都是良好的降低耦合的思想。

当然，随着技术的发展，两者的概念可能会越来越分离，各自形成一个独立的体系。