設計模式的真正境界，就是看懂，然後忘記。

單一職責原則

只幹一件事。
這個粒度越小，就越好複用，重複程式碼就越少，但是程式碼量也越多，需要自己權衡。

里氏替換原則

子類可以擴充套件父類的功能，但不能改變父類原有的功能。
可以儘量減少重複作用的類，也防止呼叫父子類同名方法造成不同的效果。
問題：繼承的層級過多，子類會很龐大，如果並不需要用父類的方法， 就很冗餘。

例子：

父親會移動，用的腿。兒子也會移動，用的車。
呼叫者想用腿走，但是呼叫兒子的移動，就會有問題。
所以要兒子實現開車方法，讓呼叫者自己選擇。

開閉原則

寫新程式碼不改老程式碼。
使用抽象類，讓不同的人實現不同的效果，實現擴充套件。

例子：

抽象類 移動
類A 實現 移動 用腿
擴充套件
類B 實現 移動 用自行車
呼叫者 自由選擇A或者B

依賴倒置原則

要面向介面程式設計，不要面向實現程式設計。
使用介面類，讓不同的人實現不同的，但是效果一致。
呼叫者呼叫的是介面，並不用關心實現，效果都一致。

例子：

介面類 購物方式
類A 實現 購物方式 上淘寶
類B 實現 購物方式 上京東

購物類 初始化注入購物方式類

呼叫者 選擇不同的購物方式類注入，然後使用購物類

介面隔離原則

減少介面依賴
提供更符合需求，更具體的介面。也就是結合業務進行封裝。

例子：

套餐。
使用者可以點牛排、麵包、麵條、花椰菜、玉米。
但是所有這些都放到一個介面類裡面，就很多。
可以提供，主食類、肉類、湯類。
或者 兒童套餐，雙人套餐，家庭套餐。
主要是結合場景對小介面進行歸類和整合。

迪米特法則

避免直接呼叫或直接通訊。
也叫層次依賴。
從依賴者的角度來說，只依賴應該依賴的物件。
從被依賴者的角度說，只暴露應該暴露的方法。

例子：

手機類 APP類 內容類
內容類就只用依賴APP，而不用依賴手機。

還有種理解，增加了呼叫者負擔。
也叫增加了API表面積，就是儘量讓呼叫者少關注實現邏輯。

例子：

一個錯誤處理方法，有幾種錯誤型別。
第一種寫法就是提供一個類，然後你根據類內的錯誤型別進行判斷。這樣一旦型別修改了就要改呼叫者的程式碼。
第二種寫法就是提供一個校驗的方法，你只用呼叫這個方法就知道是不是錯誤，或者是什麼錯誤。

合成複用原則

少用繼承，多用組合
就是將程式碼分成塊A、塊B、C..
然後製造積木1就是包含以下A和B，積木2可能就是BCD。自由組合，更靈活。

總結

Go語言還是厲害的。
直接沒有繼承，只有結構體和包，這不就是一塊一塊麼？
也沒有純虛類，只有介面，直接就是面向介面程式設計。

看完就忘掉這幾個法則把，只要記住應該怎麼做就好了，什麼是對，什麼是錯，我反正是不記得什麼原則對應什麼的，只記得應該這樣和為什麼要這樣。