Spring-DI

依赖注入(DI)，是spring容器实现的基础，在spring-core模块中实现的。所谓DI，就是指对象是被动接受依赖类而不是自己主动去找，换句话说就是指对象不是从容器中查找它依赖的类，而是在容器实例化对象的时候主动将它依赖的类注入给它。下面举一个形象的例子：

class B{
   private A a;
   public void setA(A a){
      this.a=a;
   }
}

class A{
}

 

显然，此时B是依赖与A。我们不妨将A比作牛，将B比作人，人吃牛是显然的事实。当用户要利用B的时候，必须先要指定他所依赖的A的对象。这样代码模块之间就具有很强的耦合。通过依赖注入的方式，能够使B对A的依赖关系对代码人员变得松散。我们将A和B对象都交给容器来管理，通过配置文件告诉B该依赖的A，这样代码中的依赖关系被移到了配置文件中，通过对配置文件的管理，很容易编写低耦合的代码。
对于依赖注入的几种实现参考Dependency Injection 。

 

但是，目前在学术界争论的焦点在于：DI究竟能不能给程序带来解耦。

众所周知，封装和依赖是面向对象编程思想中两个很重要的概念。编写高内聚低耦合的代码是OOP编程的目标。但是，这其中本来就存在着互相矛盾。

所谓高内聚，就是通过封装之后，是被封装的各个模块(这里一般是一个类)内部的功能功能相关性、依赖性、协作性等高。此时，我们要做的就是对模块按照上述标准进行分解，直到满意为止。但是，什么时候才是一个尽头？当我们在不断的对模块进行分解时，被分解的模块之间的耦合就不断的增强。此时，我们就会反过来想，低耦合就是不断降低模块之间的关系，没有关系最好。于是我们要做的就是模块合组，将耦合关系强的模块组合在一起。那怎么样才能做到最好？那不就是用一个统一的模块来表示整个需要描述的系统，废话那不就等于什么都没有做。说了这么多，我要说的就是要在内聚和耦合之间进行权衡，找到一个恰当的平衡点。

下面切入正题，所谓耦合，简单的理解就是模块与模块之间的关系，最主要的就是依赖关系。从上面的讨论很容易的发现模块之间的耦合是无法消除的，除非他们之间没有任何关系。那么DI为什么声称能够给程序带来解耦呢？我觉耦合并没有消除，甚至没有减弱。DI只是将耦合进行了转移，通常是转移到配置文件中。

<beans>
    <bean id="b" class="B">
        <property name="a" ref="a"/>
    </bean>
    <bean id="a" class="A">     
    </bean>
</beans>

 B对A的依赖关系原来在这里。因此，在主程序中的不再为new B的时候为A所扰心。

但是，如果我们从另外一个方面来考虑，如果我们把A和B当作两个由第三方编写代码模块，我们无法修改他的源代码。我们会发现，DI的机制就变得非常有用了。我们只需要根据需要写配置文件，告诉B所依赖的模块A到底是那个A。当A公司对A进行升级时，直接将组件进行替换；或者当我们改用C公司的模块C时，要做的只是告诉B所依赖的模块A是C公司的那个模块。这种对耦合转移的方式，在实际软件开发，尤其是基于组件或插件的开发中，意义非凡。

 

其实，回头想想我们怎么能够既要求模块之间协作又要求没有耦合呢。DI只不过是将各个开发人员之间代码的耦合转移到统一管理的地方。

但是，当系统比较大的时候，配置文件会被胀的很大，给配置编写带来了一定的难度，目前能够做的只是根据配置的bean的不同类别，将配置文件分块。

目前，貌似spring中增加了注解的功能。我个人觉得，注解的方式，确实给程序员带来了不少方便，他就相当于一部傻瓜相机，拍照的参数由相机自己来调，但是也会给开发带来一些隐含的问题。