一、概述

設計模式（Design pattern）是一套被反覆使用、多數人知曉的、經過分類編目的、程式碼設計經驗的總結。使用設計模式是為了可重用程式碼、讓程式碼更容易被他人理解、保證程式碼可靠性。 毫無疑問，設計模式於己於他人於系統都是多贏的；設計模式使程式碼編制真正工程化；設計模式是軟體工程的基石脈絡，如同大廈的結構一樣。

而設計原則則是設計模式所遵循的規則，設計模式就是實現了這些原則，從而達到了程式碼複用、增加可維護性的目的。

二、六大設計原則2.1 單一職責原則(Single Responsibility Principle - SRP)

一個類，只有一個引起它變化的原因。應該只有一個職責。每一個職責都是變化的一個軸線，如果一個類有一個以上的職責，這些職責就耦合在了一起。這會導致脆弱的設計。當一個職責發生變化時，可能會影響其它的職責。另外，多個職責耦合在一起，會影響複用性。例如：要實現邏輯和介面的分離。

2.2 開放封閉原則(Open Closed Principle - OCP)

軟體實體應該是可擴充套件，而不可修改的。也就是說，對擴充套件是開放的，而對修改是封閉的。對擴充套件開放，意味著有新的需求或變化時，可以對現有程式碼進行擴充套件，以適應新的情況。對修改封閉，意味著類一旦設計完成，就可以獨立完成其工作，而不要對類進行任何修改。封裝變化，是實現開放封閉原則的重要手段，對於經常發生變化的狀態一般將其封裝為一個抽象。拒絕濫用抽象，只將經常變化的部分進行抽象，這種經驗可以從設計模式的學習與應用中獲得。

2.3 里氏替換原則(Liskov Substitution Principle - LSP)

里氏替換原則通俗的來講就是：子類可以擴充套件父類的功能，但不能改變父類原有的功能。它包含以下4層含義：

子類可以實現父類的抽象方法，但不能覆蓋父類的非抽象方法。子類中可以增加自己特有的方法。當子類的方法過載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入引數更寬鬆。當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。

2.4 最少知識原則(Least Knowledge Principle - LKP)

最少知識原則又叫迪米特法則。核心思想是：低耦合、高內聚一個實體應當儘量少的與其他實體之間發生相互作用，使得系統功能模組相對獨立。也就是說一個軟體實體應當儘可能少的與其他實體發生相互作用。這樣，當一個模組修改時，就會盡量少的影響其他的模組，擴充套件會相對容易，這是對軟體實體之間通訊的限制，它要求限制軟體實體之間通訊的寬度和深度。

2.5 介面隔離原則(Interface Segregation Principle - ISP)

介面隔離原則的含義是：建立單一介面，不要建立龐大臃腫的介面，儘量細化介面，介面中的方法儘量少。採用介面隔離原則對介面進行約束時，要注意以下幾點：

介面儘量小，但是要有限度。對介面進行細化可以提高程式設計靈活性是不掙的事實，但是如果過小，則會造成介面數量過多，使設計複雜化。所以一定要適度。為依賴介面的類定製服務，只暴露給呼叫的類它需要的方法，它不需要的方法則隱藏起來。只有專注地為一個模組提供定製服務，才能建立最小的依賴關係。提高內聚，減少對外互動。使介面用最少的方法去完成最多的事情。

2.6 依賴倒置原則(Dependence Inversion Principle - DIP)

依賴倒置原則的核心思想是面向介面程式設計，不應該面向實現類程式設計。在實際程式設計中，要做到下面3點：

低層模組儘量都要有抽象類或介面，或者兩者都有。變數的宣告型別儘量是抽象類或介面。使用繼承時遵循里氏替換原則。

三、其他設計原則

除了以上六大設計原則之外。還有一些其他的設計原則，下面只做簡單介紹，

3.1 組合/聚合複用原則（Composition/Aggregation Reuse Principle - CARP）

當要擴充套件類的功能時，優先考慮使用組合，而不是繼承。這條原則在 23 種經典設計模式中頻繁使用，如：代理模式、裝飾模式、介面卡模式等。可見江湖地位非常之高！這也是面向物件中的一個重要原則。

3.2 無環依賴原則（Acyclic Dependencies Principle - ADP）

當 A 模組依賴於 B 模組，B 模組依賴於 C 模組，C 依賴於 A 模組，此時將出現迴圈依賴。在設計中應該避免這個問題，可透過引入“中介者模式”解決該問題。

3.3 共同封裝原則（Common Closure Principle - CCP）

應該將易變的類放在同一個包裡，將變化隔離出來。該原則是“開放-封閉原則”的延生。

3.4 共同重用原則（Common Reuse Principle - CRP）

如果重用了包中的一個類，那麼也就相當於重用了包中的所有類，我們要儘可能減小包的大小。

3.5 好萊塢原則（Hollywood Principle - HP）

好萊塢明星的經紀人一般都很忙，他們不想被打擾，往往會說：Don"t call me, I"ll call you. 翻譯為：不要聯絡我，我會聯絡你。對應於軟體設計而言，最著名的就是“控制反轉”（或稱為“依賴注入”），我們不需要在程式碼中主動的建立物件，而是由容器幫我們來建立並管理這些物件。

3.6 不要重複你自己（Don"t repeat yourself - DRY）

不要讓重複的程式碼到處都是，要讓它們足夠的重用，所以要儘可能地封裝。

3.7 保持它簡單與傻瓜（Keep it simple and stupid - KISS）

不要讓系統變得複雜，介面簡潔，功能實用，操作方便，要讓它足夠的簡單，足夠的傻瓜。

3.8 高內聚與低耦合（High Cohesion and Low Coupling - HCLC）

模組內部需要做到內聚度高，模組之間需要做到耦合度低。

3.9 慣例優於配置（Convention over Configuration - COC）

儘量讓慣例來減少配置，這樣才能提高開發效率，儘量做到“零配置”。很多開發框架都是這樣做的。

3.10 命令查詢分離（Command Query Separation - CQS）

在定義介面時，要做到哪些是命令，哪些是查詢，要將它們分離，而不要揉到一起。

3.11 關注點分離（Separation of Concerns - SOC）

將一個複雜的問題分離為多個簡單的問題，然後逐個解決這些簡單的問題，那麼這個複雜的問題就解決了。難就難在如何進行分離。

3.12 契約式設計（Design by Contract - DBC）

模組或系統之間的互動，都是基於契約（介面或抽象）的，而不要依賴於具體實現。該原則建議我們要面向契約程式設計。

3.13 你不需要它（You aren"t gonna need it - YAGNI）

不要一開始就把系統設計得非常複雜，不要陷入“過度設計”的深淵。應該讓系統足夠的簡單，而卻又不失擴充套件性，這是其中的難點。

設計模式是一套被反覆使用的、多數人知曉、經過分類編目的優秀程式碼設計經驗的總結。特定環境下特定問題的處理方法。1）重用設計和程式碼 重用設計比重用程式碼更有意義，自動帶來程式碼重用2）提高擴充套件性 大量使用面向介面程式設計，預留擴充套件插槽，新的功能或特性很容易加入到系統中來3）提高靈活性 透過組合提高靈活性，可允許程式碼修改平穩發生，對一處修改不會波及到其他模組4） 提高開發效率 正確使用設計模式，可以節省大量的時間