設計原則利劍五--迪米特法則

英文名稱：Law of Demeter(Lod),或者最少知識原則(Least Knowledge Principle)

中文名稱：迪米特法則

作      用：其核心觀點就是類見解耦，弱耦合，使得了解與執行都簡潔便利

深刻了解：一個對象應該對其他對象有最少的了解，并且一個對象應該盡量減少對外公布接口，猶如公司架構，CEO直接上司總監，總監直接上司經理，經理直接上司普通員工，每個角色都有各自的接口，CEO不需要直接對普通員工發出指令也沒有必要，隻有這樣公司架構才能夠穩定，才能夠執行快，其中包括了4個層次的含義

            1、隻和朋友交流，也就是在類設計的時候，一定要注意隻與自己有關系的類進行溝通，如果出現在成員變量，方法的輸入輸出參數中，那麼我們可以将這個類定義為我的朋友，否則，盡量不要用其他類

            2、朋友間也是有距離的，在類的設計的時候，要盡量使借口操作簡單，能放在内部完成的工作一定要在本類中完成，而不是讓你的朋友進行一步一步的操作，如CEO要購買一個電腦，總監下達指令買電腦過來，然後送出給他就行，不要買什麼牌子，買什麼價格，買多重的，讓誰去買，在什麼地方去買都需要CEO來進行操作，完全沒有必要，隻需要一個簡單的借口就行，是以在定義public方法的時候，一定要慎重再慎重

            3、是自己的就是自己的，這就相當于工作職責的劃分，需要電腦是CEO的事情，買什麼價位的決定是總監的事情，讓誰去買時經理的事情，買什麼牌子是網管的事情，如果一個方法放在本類中，既不增加類間關系，也對本類不産生負面影響，就放在本類中，如果方法會增加類之間的關系，那麼久要考慮放在這裡是否恰當，就好像要讓CEO決定買什麼品牌的電腦一樣，CEO要去問總監什麼價位的性能合适，還要問經理誰懂電腦行情，最後還要問網管什麼牌子的電腦好，這個決定買什麼品牌的方法放在CEO類中是絕對不合适的。當然這個也隻是一個簡單的比喻，可能不太恰當，了解事情的真谛就行。

            4、謹慎使用Serializable

理論實踐：

           了解了上面這麼多，覺得用簡單點的話語概述為：接口盡量少，方法中不要引用到沒有與本類發生關系的類         

           來看看一個老師讓體育委員清點女生數量的案例，在下面的設計方案中，老師與女生類之間有關系，這種設計非常的不合理，根據迪米特法則，一定不要在方法中使用不是朋友的類，否則會讓類的結構複雜難以處理，為何這個老師不輕松一點，根本就不去管女生，而直接發一個指令給體育委員統計資料就行呢？先看看這個不合理的設計圖：

        明顯上面的設計非常差勁，讓我們看看下面的設計，老師不再與女生發生關系，多簡潔。

       迪米特法則還是讓我想起了CEO要買電腦的案例，如下圖所示，試想想如果CEO要想指定**人去買**電腦，那将會是多麼負責的一個工程，這個UML圖将會是多麼的複雜，我不敢想象