小菜學設計模式——迪米特原則

    背景

    本文標題爲何叫小菜學習設計模式，緣由是本文內容主要是學習《大話設計模式》時的筆記摘要部分，固然，並非記錄書中小菜的學習過程，這個徹底沒有意義，而是指本人學習設計模式的成長之旅。

    真誠的但願本身可以從一名小菜成長爲一名大鳥！

    編寫的程序應該知足：

    1）可維護

    2）可擴展

    3）可複用

    4）夠靈活

    廢話少說，言歸正傳，設計模式原則之：迪米特原則（最少知識原則）

    書面理解

    迪米特原則：若是兩個類沒必要彼此直接通訊，那麼這兩個類就應當發生直接的相互做用。若是其中一個類須要調用另外一個類的某一個方法的話，能夠經過第三者轉發這個調用。

    迪米特法則強調的前提是在類的結構設計上，每個類都應當儘可能下降成員的訪問權限，也就是說，一個類包裝好本身的private狀態，不須要讓別的類知道的字段或行爲就不要公開，其實就是在封裝一個類的時候儘可能明確這個類的屬性和操做屬性的方法。

    迪米特法則的根本思想，是強調類本身的鬆耦合。

    類之間的鬆耦合越弱，越有利於複用，一個處在弱耦合的類被修改，不會對有關係的類形成波及，換句話說，信息隱藏促進了軟件的複用。

    我的的理解

    迪米特法則也被稱之爲最少知識原則。所謂最少知識不是這個類的功能越弱越好，前面說過對類定義只要知足單一職責，而是，但願這個類暴露在外面的東西越少越好。之前只知道使用private能夠保護成員變量不被外界直接操做，從而加強了類的安全性。如今，發現private不只有安全性還能夠下降類之間的耦合性。當兩個類之間沒有直接聯繫的時候，那麼這兩個類的耦合度會變低，從而更容易擴展了。

    生活中的具體實例，小時候很喜歡問數學題，下課後總喜歡拿着數學卷子往數學教學小組辦公室跑，由於，很差意思因此每次都是拿着卷子直接找咱們的數學授課老師李老師，這就至關於我只認識數學李老師一我的，把其餘數學老師都忽略了，那麼我和李老師構成了一種直接的依賴關係。結果有一天，李老師有事不在，那麼個人問題就不能馬上解決，這時問題來了，其餘老師都很閒，並且他們也必定可以幫我解決這個問題，但是由於我只會問李老師，因此錯過了解決問題的機會。若是把數學教學小組看作一個抽象的接口，而我直接調用這個接口的方法，那麼就是，我去辦公室問題老師題目，全部老師當中總有一個會幫我來解決問題。而數學小組的人員構成我不用知道，老師是如何解決我也不用知道，總之這個問題交付給他們，他們就要給出答覆。

    總結一下，類與類之間調用時，若是一個類須要被擴展，或者預計後期會發生變化，那麼最好採用調用這個類的接口，這樣面向接口編程而不是面向過程（具體）編程，這樣其實解決了類與類之間的直接耦合關係。爲了更好的解決這種耦合關係，咱們應該儘可能把一個類封裝得安全私有，一類沒必要要暴露的屬性儘可能不要被外界調用，把他設爲本身的私有屬性或方法。