Posted on 2005-12-06 15:56
大阿福 閱讀(1014)
評論(0) 編輯 收藏 所屬分類:
Java
每次讀《Ioc容器和Dependency Injection模式》都會有新的體會，正好印證了“書讀百遍，其義自現”這句古話。
就跟其他的設計模式乃至其他的軟件開發技術一樣，DIP也有自身適合的應用場景：如何在組裝不同的軟件組件時進行最大程度的解耦，達到更好的接口與實現的分離。這種不同的軟件組件更側重指在大型的軟件系統中，由不同的人開發出來等待組合的情況。所以對于簡單較小的桌面應用程序（僅僅是個人使用，或是沒有靈活的架構需求），則是無需考慮過多的模式問題。
控制反轉，我在最初接觸到這個概念的時候一直沒能明白，再讀文章給了我進一步領會的機會。原來
在我們一般進行代碼設計的時候，在某個對象依賴另一個時，一般會直接new一個出來，這本身就是一個強耦合的典型，在需要靈活的程序結構和運行時才決定實現類的需求下，這樣的實現無疑增大了維護的難度和浪費。控制反轉則是由第三方（Ioc容器）來提供被依賴對象，依賴者僅需提供所需接口及服務聲明即可。
關于解耦，正如文中所提，ServiceLocator也是一種良好的模式，MF在文中對這兩種模式做了較為詳盡的比較，甚至更傾向于SL模式提供的更為直觀的接口的方式，但是如果SL的設計本身也是個問題，設計的優劣，將影響解耦程度的高低，文中給出了為定位器提供分離的接口和動態服務定位器兩種方案。
現在較為流行的Ioc容易有PicoContainer和Spring，尤其是后者，現在可以說是如日中天，可惜手頭的工作一直未能采用這些先進的框架和容器技術，希望能在E5重構中實踐。