六大設計原則
一、單一職責原則
1.定義：應該有且僅有一個原因引起類的變更。
2.單一職責的好處
a.類的複製性降低，實現什麼職責都有清晰明確的定義
b.可讀性提高，複雜性降低，那當然可讀性提高了
c.可維護性的提高，可讀性提高，當然更容易維護
d.變更引起的風險降低，本身變更是必不可少的，介面的單一職責做的好，一個介面修改只針對響應的實現類有影響，對其他介面無影響，對系統的擴充套件性和維護性都有非常大的幫助
3.總結：現實中想要全部按照單一職責原則很難在專案中得到提現，需要考慮的問題比較多，環境、工作量、人員技術水平以及資源等等；對於介面再設計的時候一定要做到單一；而對於實現類就需要多方面考慮；生搬硬套單一職責原則會引起類的劇增，反而給維護帶來非常多的麻煩；俗話說原則是死的人是活的；具體問題還需據對應對
4.結合我們酷客多產品介面設計案列，非常明顯可以體驗出單一職責的好處
例如：酷客多小程式產品詳情頁面，相對將頁面價格資訊和促銷資訊資料的獲取獨立成兩個單獨介面；酷客多營銷外掛的更新迭代是比較頻繁，不時新增一種營銷外掛；而將促銷資訊介面獨立出後，後續無論增加多少種外掛，也只需要調整促銷資訊介面即可，對應商品詳情其他資料介面無需任何改動。
二、里氏替換原則
1.定義：
a.如果對每一個型別為S的物件01，都有型別為T的物件02，使得以T定義的所有程式P在所有的物件01都帶換成02時，程式P的行為沒有發生變化，那麼型別S是型別T的子型別
b.所有引用基類的地方必須能透明地使用其子類的物件；通俗的說，就是所有能使用父類的地方都可以替換為子類，不會產生任何錯誤或異常，但是反過來就不行了，有子類出現的地方，父類未必就能適應
2.規範:
a.子類必須完全實現父類的方法
i.做系統設計時，經常會定義一個介面或抽象類，然後編碼實現，呼叫類則直接傳入介面或抽象類，這裡就是使用了里氏替換原則
ii.在類種呼叫其它類時務必要使用父類或介面，如果不能使用父類或介面，則說明類的設計已經違背了LSP原則
iii.如果子類不能完整地實現父類的方法，或者父類的某些方法在子類中已經發生“畸變”，則建議斷開負責繼承關係，採用依賴、聚集、組合等關係代替繼承
b.子類可以有自己的個性,子類同時也可以有屬於自己的屬性和方法
c.覆蓋或實現父類的方法時輸入引數可以被放大
d.覆寫或實現父類的方法時輸出結果可以被縮小
三、依賴倒置原則
1.定義：
a.高層模組不應該依賴底層模組，兩則都應該依賴其抽象
b.抽象不應該依賴細節
i.什麼是抽象:抽象就是指介面或抽象類，兩者都是不能直接被例項化的
ii.什麼是細節:細節就是實現類，實現介面或繼承抽象類而產生的類就是細節，特點就是可以直接例項化，也就是new產生一個物件
c.細節應該依賴抽象
2.作用：依賴倒置原則可以減少類間的耦合性，提高系統的穩定性，降低並行開發引起的風險，提高程式碼的可讀性和可維護性
3.依賴的三種寫法
a.建構函式傳遞依賴物件
b.Setter方法傳遞依賴物件
c.介面宣告傳遞依賴物件
四、介面隔離原則
1.定義:
a.客戶端不應該依賴它不需要的介面。依賴是什麼？依賴它需要的介面，客戶端需要什麼介面就提供什麼介面，把不需要的介面剔除掉，對介面進行細化，保證介面的純潔性
b.類間的依賴關係應該建立在最小的介面上。最小的介面也是需要細化的，介面的純潔性如上，只是一個實物的兩種不同的描述
2.介面隔離原則的四層含義
a.介面要儘量小
b.介面要高內聚
c.定製服務
d.介面設計是有限度的
3.總結：
a.一個介面只服務於一個子模組或業務邏輯
b.通過業務邏輯壓縮介面中的public方法，介面時常去回顧，儘量讓介面達到“滿身筋骨肉”，而不是“肥嘟嘟”的一大堆方法；
c.已經汙染了的介面，儘量去修改，若變更的風險比較大，則採用介面卡模式進行轉化處理。介面卡模式可以單獨查閱設計模式一書中相關資訊
d.瞭解環境，拒絕盲從。每個專案或產品都有特定的化境因素，別看到大師是這樣做的你就照抄；環境不同，介面拆分的標準就不同。
五、迪米特法則
1.定義：迪米特法則也稱為最小知識原則，描述的規則：一個物件應該對其他物件有最少的瞭解，通俗的說，一個類應該對自己需要耦合或呼叫的類知道的最少，你的內部是如何複雜和我沒關係，我就知道你提供的這麼公開方法，我就呼叫這麼多，其他一概不關心
2.迪米特法則對類的低耦合提出了明確要求，其包含3層含義
a.只和朋友交流。兩個物件之間的耦合就成為朋友關係，這種關係的型別有很多，例如組合、聚合‘依賴等
b.朋友間也是有距離的。一個類公開的屬性或方法越多，修改時涉及的面也就越大，變更引起的風險擴散也就越大，因此為了保持距離，設計時需要反覆衡量減少public方法和屬性。
c.是自己的就是自己的：如果一個方法放在奔雷中，既不增加類間關係，對本類不產生負面影響，那就放置在本類中
3.總結：迪米特法則的核心觀念就類間解耦，弱耦合，只有弱耦合了以後，類的複用率才可以提高，而這樣的要求結果回產生大量的中轉和跳轉類，導致系統的複雜性提供，同時也為維護帶來了難度。因此，在實際專案中，需要適度地考慮這個原則，別為了套用原則而做專案。視情況而定。
六、開閉原則
1.定義：一個軟體實體如類、模組和函式應該對擴充套件開放，對修改關閉。
擴充套件開放：意思是指當我們針對一個需求有變化時，我們通過擴充套件來實現變化，，這樣對系統的最小化開發，修改也少，風險也小
修改關閉：關閉修改應該變化，這樣極大降低系統的風險，保持歷史程式碼的純潔性，提高系統的穩定性。
2.好處
a.開閉原則可以提供複用性
b.開閉原則可以提供可維護性
3.總結：開閉原則是一個非常虛地原則，前面5個原則是對開閉原則地具體解釋，但是開閉原則並不侷限這麼多，它“虛”得沒有邊界，就像“好好學習，天天向上”得口號一樣，告訴我們要好好學習，但是學什麼，怎麼學沒有告訴我們，需要我們去體會和掌握，開閉原則也是一樣。
六大設計原則總結
六大設計原則得核心其實是開閉原則，開閉原則具有理想主義的色彩，它是物件導向設計的終極目標。因此，針對開閉原則的實現方法，一直都有物件導向設計的大師費盡心機，研究開閉原則的實現方式。而對於其他五大設計原則，都可以看作是開閉原則的實現方法。
作者：酷客多小程式 劉慈