單一職責原則，就乙個類而言，應該僅有乙個引起它變化的原因。
如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。
軟體設計真正要做的許多內容，就是發現職責並把那些職責相互分離[asd]。
如何判斷？
開放-封閉原則，軟體實體（類、模組、函式等等）可以擴充套件，但不可修改。
也就是對擴充套件開放，對更改封閉。
該原則要求，你在設計的時候，就該讓乙個類足夠的好，在之後的過程中，不要修改這個寫好的類，而是去新增乙個類。
但說實話，絕對的封閉是不可能的，所以我們只能再設計的時候盡可能的猜測可能變化的種類，然後構造抽象來隔離變化。
如果真的出現了變化，必須修改之前寫好的類，那麼我們就需要遵循變化發生立即採取行動，也就是將這個寫好的類立刻抽象，便於下次如果再新增功能好新增功能。
舉個例子：
我們希望的是在開發工作展開不久就知道可能發生的變化。查明可能發生的變化所等待的時間越長，要建立正確的抽象就越困難。
依賴倒轉原則，原話解釋是：抽象不應該依賴細節，細節應該依賴於抽象。簡單講就是：依賴介面程式設計，再乙個就是高層模組不應該依賴低層模組，而是依賴抽象（介面）
舉個例子：
黎克特制代換原則，子類必須能夠替換掉他們的父型別。
也就是說，在程式裡，將所有的父類都替換成它的子類，程式的行為沒有變化。
怎麼理解上述呢？其實就是，父類的功能子類全部都有，子類可以拓展新的功能。
上**釋一下，動物可以吃、喝、跑、叫，那麼我的貓類也實現了吃、喝、跑、叫，那麼我將所有的動物都替換成貓，程式也在執行這四種行為。這時才表明父類真正的被復用，如果想有別的動物，也必須實現動物類裡的吃、喝、跑、叫四個功能。
迪公尺特法則，如果兩個類不必彼此直接通訊，那麼這兩個類就不應當發生直接的相互作用。如果其中乙個類需要呼叫另乙個類的某乙個方法的話，可以通過第三者**這個呼叫。
只與直接的朋友通訊。首先來解釋一下什麼是直接的朋友：每個物件都會與其他物件有耦合關係，只要兩個物件之間有耦合關係，我們就說這兩個物件之間是朋友關係。耦合的方式很多，依賴、關聯、組合、聚合等。其中，我們稱出現成員變數、方法引數、方法返回值中的類為直接的朋友，而出現在區域性變數中的類則不是直接的朋友。也就是說，陌生的類最好不要作為區域性變數的形式出現在類的內部。
迪公尺特法則引用
設計模式6大原則 迪公尺特法則
迪公尺特法則 law of emeter 定義 乙個物件應該對其他物件了解最少 迪公尺特法則的核心觀念就是類間解耦，弱耦合，只有弱耦合了以後，類的復用性才可以提高。形象一點的比喻類似於 監獄內的犯人是不應該跟外面的人接觸的，當然或許會有探親的。這裡的監獄就是類，裡面的犯人就是類內部的資訊，而監獄裡的...
設計模式六大原則 迪公尺特法則
背景 在學校學習時，可能因為某些事你得去其他二級學院的老師幫忙，大部分老師都是忙的 也許是的 很可能一件小事你要跑很多次。但是如果 你這件事直接找的是其他學院的院長，並且院長同意幫忙的話這件事解決起來就容易多了。不知怎地最近老是瞎想感覺這件事又能和設計模式中的迪公尺特法則 law of demete...
設計模式六大原則 迪公尺特法則
設計模式總覽 迪公尺特法則 law of demeter 又叫作最少知識原則 least knowledge principle 簡寫lkp 就是說乙個物件應當對其他物件有盡可能少的了解,不和陌生人說話。這樣就能有效降低耦合了。特點 1 只和 朋友 聯絡 2 就算是 朋友 也要少建立聯絡 用途 降耦...