Spring -di依赖注入

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

Java代码  

1. class B{  
2.    private A a;  
3.    public void setA(A a){  
4.       this.a=a;  
5.    }  
6. }  
7.   
8. class A{  
9. }  

 

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

 

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

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

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

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

Java代码  

1. <beans>  
2.     <bean id="b" class="B">  
3.         <property name="a" ref="a"/>  
4.     </bean>  
5.     <bean id="a" class="A">       
6.     </bean>  
7. </beans>  

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

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

 

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

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

目前，貌似spring中增长了注解的功能。我我的以为，注解的方式，确实给程序员带来了很多方便，他就至关于一部傻瓜相机，拍照的参数由相机本身来调，可是也会给开发带来一些隐含的问题。