迪米特法則來自於1987年美國東北大學(Northeastern University)一個名爲「Demeter」的研究項目。迪米特法則又稱爲最少知識原則(LeastKnowledge Principle, LKP),其定義以下:函數
迪米特法則(Law of Demeter, LoD):一個軟件實體應當儘量少地與其餘實體發生相互做用。this |
若是一個系統符合迪米特法則,那麼當其中某一個模塊發生修改時,就會盡可能少地影響其餘模塊,擴展會相對容易,這是對軟件實體之間通訊的限制,迪米特法則要求限制軟件實體之間通訊的寬度和深度。迪米特法則可下降系統的耦合度,使類與類之間保持鬆散的耦合關係。spa
迪米特法則還有幾種定義形式,包括:不要和「陌生人」說話、只與你的直接朋友通訊等,在迪米特法則中,對於一個對象,其朋友包括如下幾類:設計
(1) 當前對象自己(this);對象
(2) 以參數形式傳入到當前對象方法中的對象;事件
(3) 當前對象的成員對象;ip
(4) 若是當前對象的成員對象是一個集合,那麼集合中的元素也都是朋友;ci
(5) 當前對象所建立的對象。開發
任何一個對象,若是知足上面的條件之一,就是當前對象的「朋友」,不然就是「陌生人」。在應用迪米特法則時,一個對象只能與直接朋友發生交互,不要與「陌生人」發生直接交互,這樣作能夠下降系統的耦合度,一個對象的改變不會給太多其餘對象帶來影響。it
迪米特法則要求咱們在設計系統時,應該儘可能減小對象之間的交互,若是兩個對象之間沒必要彼此直接通訊,那麼這兩個對象就不該當發生任何直接的相互做用,若是其中的一個對象須要調用另外一個對象的某一個方法的話,能夠經過第三者轉發這個調用。簡言之,就是經過引入一個合理的第三者來下降現有對象之間的耦合度。
在將迪米特法則運用到系統設計中時,要注意下面的幾點:在類的劃分上,應當儘可能建立鬆耦合的類,類之間的耦合度越低,就越有利於複用,一個處在鬆耦合中的類一旦被修改,不會對關聯的類形成太大波及;在類的結構設計上,每個類都應當儘可能下降其成員變量和成員函數的訪問權限;在類的設計上,只要有可能,一個類型應當設計成不變類;在對其餘類的引用上,一個對象對其餘對象的引用應當降到最低。
下面經過一個簡單實例來加深對迪米特法則的理解:
Sunny軟件公司所開發CRM系統包含不少業務操做窗口,在這些窗口中,某些界面控件之間存在複雜的交互關係,一個控件事件的觸發將致使多個其餘界面控件產生響應,例如,當一個按鈕(Button)被單擊時,對應的列表框(List)、組合框(ComboBox)、文本框(TextBox)、文本標籤(Label)等都將發生改變,在初始設計方案中,界面控件之間的交互關係可簡化爲如圖1所示結構: 圖1 初始設計方案結構圖 在圖1中,因爲界面控件之間的交互關係複雜,致使在該窗口中增長新的界面控件時須要修改與之交互的其餘控件的源代碼,系統擴展性較差,也不便於增長和刪除新控件。 現使用迪米特對其進行重構。 |
在本實例中,能夠經過引入一個專門用於控制界面控件交互的中間類(Mediator)來下降界面控件之間的耦合度。引入中間類以後,界面控件之間再也不發生直接引用,而是將請求先轉發給中間類,再由中間類來完成對其餘控件的調用。當須要增長或刪除新的控件時,只需修改中間類便可,無須修改新增控件或已有控件的源代碼,重構後結構如圖2所示: