依賴注入對設計有利，而spring則促進了依賴注入的使用。
如果業務處理類，它所使用的倚賴，都是依靠在這個類內部實現或者查詢，那麼必然使得正常的業務邏輯和獲取依賴的方法混在一起。
我取個最簡單的場景，某個註冊的工作類，它需要獲取當前"容許的使用者名稱的最大長度"，這個依賴非常簡單吧？基本每個註冊類都有這個限制，我們現在把場景考慮的全面一點，對於複雜一點的系統，這個最大長度的限制可能**很多，比如配製檔案，資料庫，可能類工作在前台比如web而配製在後台，可能需要和第三放系統一起工作而需要到第三方系統中獲取而對方只提供web service...
這麼乙個簡單的依賴，「使用者名稱的最大長度」，如果用依賴注入，只要乙個簡單的setusernamemaxlength()方法就可以搞定。考慮上面那麼多種可能都出現，最惡劣的情況是要求乙個系統可以同時支援然後通過配製方式進行，這對於將乙個產品賣給n家客戶的公司來說是最正常不過的要求。
那麼我們來看乙個很有"spring"風格的採用依賴注入的設計，通常都將會是這樣：
註冊工作類：
public void registerwork
....
}「使用者名稱的最大長度」的提供者介面
public inte***cd usernamemaxlengthprovider
「使用者名稱的最大長度」的提供者則可以有以下實現，都只負責讀取資料，不關心資料被誰使用，怎麼使用：
1.直接提供，可以用spring 建構函式方式注入usernamemaxlength值，也可以junit測試時直接new directdprovide物件
public class directdprovider implements usernamemaxlengthprovider
public directdprovider (int usernamemaxlength)
}2.讀本地配製檔案
public class localconfigfileprovider implements usernamemaxlengthprovider
}3.類似的從資料庫讀取 databaseprovide
4.類似的web service從第三方讀取 webserviceprovider
5.其他的可能擴充套件的方式
開發時邏輯清晰，**可讀性超強，基本看類名和函式名搞定。測試時，輕鬆測試registerwork，testcase中只要worker.setusernamemaxlengthprovider(new directdprovider(20))就搞定。而針對usernamemaxlengthprovider的幾個實現類，更是輕鬆使用junit，每個都覆蓋一遍。
呵呵，現在我們可以砍刀，最簡單的乙個int型的「使用者名稱的最大長度」，都可能遭遇如此複雜的場景。如果不用倚賴注入，而是選擇在registerwork中自己搞定「使用者名稱的最大長度」的獲取，那麼可能要遇到以下問題：
1. registerwork極其複雜，可以想像類似的依賴肯定還有其他
2. 獲取「使用者名稱的最大長度」的方式和註冊的業務處理邏輯完全沒有直接聯絡，對註冊過程來說它只關注結果，「使用者名稱的最大長度」是10還是20，而不是到底讀本地檔案還是讀資料庫。喧賓奪主了，次要邏輯干擾了主要邏輯
3. 難於測試。獲取「使用者名稱的最大長度」的方式的這些**，被藏在registerwork類中，而且很有可能是private方法不對外暴露（如果不依賴注入還需要暴露嗎？暴露給誰呢），怎麼用mock測試？怎麼能保證以上幾種的實現都覆蓋到？
4. 難於擴充套件。就算上面都搞定了，某一天突然來了乙個**需求，要求用ldap從另乙個地方取配置呢？難道再把ldap請求的那一大片**也寫到registerwork裡面？
6. 容易出錯。剛**完成上面的**需求，更新完畢，一會客戶**來了，「...怎麼...不正常了？」。又**幾公升地檢查，終於找出來了，原來是剛才寫ladp訪問的**時不小心改錯了registerwork的乙個地方，誰讓registerwork類有幾十上百個方法好幾千行呢，一時急，又沒有測試到......可是客戶不會理解的。
上述的場景，spring + 依賴注入的設計方式，優點很明顯吧。
再考慮一下維護和二次開發的問題，上面的spring + 依賴注入的**，好看易懂，方便擴充套件，維護起來輕鬆。如果是那麼堆在registerwork裡面，在那個大堆中**要找出這些**並讀懂，估計不是件輕鬆的事情。
**維護是需要成本的，寫出易於維護的**，是乙個優秀程式設計師的基本素養，至少，不能讓下乙個接手的人罵娘吧？
spring 依賴注入 Spring依賴注入
依賴注入 dependency injection，簡稱di 與控制反轉 ioc 的含義相同控制反 在使用spring框架之後，物件的例項不再由呼叫者來建立，而是由spring容器來建立，spring容器會負責控制程式之間的關係，而不是由呼叫者的程式 直接控制，這樣控制權由應用程式轉移到了sprin...
Spring依賴注入
所謂依賴注入，是指在程式執行過程中，如果需要呼叫另乙個物件協助時，無須在 中建立按被呼叫者，而是依賴外部注入。spring 的依賴注入對呼叫者和被呼叫者幾乎沒有任何要求，完全支援對 pojo 之間依賴關係的管理。依賴注入的兩種方式 1 設值注入 設值注入是指通過 setter 方法傳入被呼叫者的例項...
SPring依賴注入
所謂依賴注入，是指在程式執行過程中，如果需要呼叫另乙個物件協助時，無須在 中建立按被呼叫者，而是依賴外部注入。spring的依賴注入對呼叫者和被呼叫者幾乎沒有任何要求，完全支援對pojo之間依賴關係的管理。依賴注入的兩種方式 1 設值注入 設值注入是指通過setter方法傳入被呼叫者的例項。這種注入...