JWorld@TW the best professional Java site in Taiwan
      註冊 | 登入 | 全文檢索 | 排行榜  

» JWorld@TW » Java Application Framework » DI/IOC  

按列印兼容模式列印這個話題 列印話題    把這個話題寄給朋友 寄給朋友    訂閱主題
reply to topicthreaded modego to previous topicgo to next topic
本主題所含的標籤
無標籤
作者 [心得] 相依反轉
qrtt1





發文: 1748
積分: 31
於 2006-04-23 01:49 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
Robert C. Martin
C++ Report, 1996
http://www.objectmentor.com/resources/articles/dip.pdf

在閱讀良葛格的SpringGossip時,有幸能閱讀IoC 概念的源頭: 依賴反轉。
看過其他討論串對於這個概念以多型的觀念一言以蔽之。但是他就純粹是,
多型涵概的住的嗎? 幾經回想之後,多型只是達成相依反轉的手段。

在文中所描述的系統有什麼樣的困境? 系統的功能與實作緊密地結合起來,
這是文中所描述: 以傳統結構化的方式來規劃程式很" 正常 "的結果。程式
由主要的功能區分,再依這些功能一一實作之,再拼裝回去。所以,在整個
系統的概念上,較高層次的事務,被底層的事物所牽動。一旦置換了底層的
實作,高層次的程式也被牽動而需要修改。

而以物件導向設計的觀點,有幾種方式可以達成內聚力高並且與其他功能低
藕合的實作方式。在設計上,要先劃分出經常變動與較穩定的區塊,各自封
裝起來。並且透過抽象的介面來組合真正要實作的系統,不讓物件實例等細
節之物有所牽連。即為文中所提的:

A. HIGH LEVEL MODULES SHOULD NOT DEPEND UPON LOW
LEVEL MODULES. BOTH SHOULD DEPEND UPON ABSTRACTIONS.

B. ABSTRACTIONS SHOULD NOT DEPEND UPON DETAILS. DETAILS
SHOULD DEPEND UPON ABSTRACTIONS.

若以較通俗的例子來解釋,大致上可以這樣想: 一個電燈實體包含一個開關
實體是不被建議的實作方式。當我們有n 種電燈與m 種開關,每一種電燈所
配上的開關可不盡相同! 最壞的情況是n 種燈與m 種開法,只要燈一換掉開
關就需要被換掉。燈與開關有強烈的交互相依關係,因此" 依賴反轉原則 "
就是提出另一種的概念來決解實作細節上過於相依的問題,目的就是達成類
別的複用性,依要相依於抽象的中介類別! 對開關實體來講,他只知道有一
個抽象的電燈要他去開啟,他並無法知道實體的電燈是那一種。所以有的物
件都通過共通的介面來操作,不僅符合物件封裝的特性,也保持了物件之間
優雅的低藕合關係。


reply to postreply to post
» JWorld@TW »  Java Application Framework » DI/IOC

reply to topicthreaded modego to previous topicgo to next topic
  已讀文章
  新的文章
  被刪除的文章
Jump to the top of page

JWorld@TW 本站商標資訊

Powered by Powerful JuteForum® Version Jute 1.5.8