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中增長了註解的功能。我我的以爲，註解的方式，確實給程序員帶來了很多方便，他就至關於一部傻瓜相機，拍照的參數由相機本身來調，可是也會給開發帶來一些隱含的問題。