一、單一職責原則（ＳＲＰ）

       就一個類而言，應該僅有一個引起它變化的原因。軟體設計真正要做的許多內容，就是發現職責並把那些職責相互分離。測試驅動的開發實踐常常會在設計出現臭味之前就迫使我們分離職責。

       二、開閉原則（ＯＣＰ）

       軟體實體（類、模組、函式）應該是可擴充套件的，但是不可修改的。也就是說：對於擴充套件是開放的，對於更改是封閉的。怎樣可能在不改動模組原始碼的情況下去更改它的行為呢？怎樣才能在無需對模組進行改動的情況下就改變它的功能呢？關鍵是抽象！因此在進行面向物件設計時要儘量考慮介面封裝機制、抽象機制和多型技術。該原則同樣適合於非面向物件設計的方法，是軟體工程設計方法的重要原則之一。

       三、替換原則（ＬＳＰ）

       子類應當可以替換父類並出現在父類能夠出現的任何地方。這個原則是Liskov於1987年提出的設計原則。它同樣可以從Bertrand Meyer 的DBC (Design by Contract〔基於契約設計〕) 的概念推出。

       四、依賴倒置原則（ＤＩＰ）

１、高層模組不應該依賴於低層模組。二者都應該依賴於抽象。２、抽象不應該依賴於細節。細節應該依賴於抽象。在進行業務設計時，與特定業務有關的依賴關係應該儘量依賴介面和抽象類，而不是依賴於具體類。具體類只負責相關業務的實現，修改具體類不影響與特定業務有關的依賴關係。在結構化設計中，我們可以看到底層的模組是對高層抽象模組的實現（高層抽象模組通過呼叫底層模組），這說明，抽象的模組要依賴具體實現相關的模組，底層模組的具體實現發生變動時將會嚴重影響高層抽象的模組，顯然這是結構化方法的一個"硬傷"。面向物件方法的依賴關係剛好相反，具體實現類依賴於抽象類和介面。

五、介面分離原則（ＩＳＰ）

採用多個與特定客戶類有關的介面比採用一個通用的涵蓋多個業務方法的介面要好。　　ISP原則是另外一個支援諸如COM等元件化的使能技術。缺少ISP，元件、類的可用性和移植性將大打折扣。這個原則的本質相當簡單。如果你擁有一個針對多個客戶的類，為每一個客戶建立特定業務介面，然後使該客戶類繼承多個特定業務介面將比直接載入客戶所需所有方法有效。

以上五個原則是面向物件中常常用到的原則。此外，除上述五原則外，還有一些常用的經驗諸如類結構層次以三到四層為宜、類的職責明確化（一個類對應一個具體職責）等可供我們在進行面向物件設計參考。但就上面的幾個原則看來，我們看到這些類在幾何分佈上呈現樹型拓撲的關係，這是一種良好、開放式的線性關係、具有較低的設計複雜度。一般說來，在軟體設計中我們應當儘量避免出現帶有閉包、迴圈的設計關係，它們反映的是較大的耦合度和設計複雜化。

---------------------------------------------------------------------------------------------------------

“你不必嚴格遵守這些原則，違背它們也不會被處以宗教刑罰。但你應當把這些原則看成警鈴，若違背了其中的一條，那麼警鈴就會響起。”

                                                                                  ----------摘抄自《OOD 啟思錄》--Arthur J.Riel 著 鮑志雲 譯

(1)所有資料都應該隱藏在所在的類的內部。

(2)類的使用者必須依賴類的共有介面，但類不能依賴它的使用者。

(3)儘量減少類的協議中的訊息。

(4)實現所有類都理解的最基本公有介面[例如，拷貝操作(深拷貝和淺拷貝)、相等性判斷、正確輸出內容、從ASCII描述解析等等]。

(5)不要把實現細節(例如放置共用程式碼的私有函式)放到類的公有介面中。

如果類的兩個方法有一段公共程式碼，那麼就可以建立一個防止這些公共程式碼的私有函式。

(6)不要以使用者無法使用或不感興趣的東西擾亂類的公有介面。

(7)類之間應該零耦合，或者只有匯出耦合關係。也即，一個類要麼同另一個類毫無關係，要麼只使用另一個類的公有介面中的操作。

(8)類應該只表示一個關鍵抽象。

包中的所有類對於同一類性質的變化應該是共同封閉的。一個變化若對一個包影響，則將對包中的所有類產生影響，而對其他的包不造成任何影響 .

(9)把相關的資料和行為集中放置。

設計者應當留意那些通過get之類操作從別的物件中獲取資料的物件。這種型別的行為暗示著這條經驗原則被違反了。

(10)把不相關的資訊放在另一個類中(也即：互不溝通的行為)。

朝著穩定的方向進行依賴.

(11)確保你為之建模的抽象概念是類，而不只是物件扮演的角色。

(12)在水平方向上儘可能統一地分佈系統功能，也即：按照設計，頂層類應當統一地共享工作。

(13)在你的系統中不要建立全能類/物件。對名字包含Driver、Manager、System、Susystem的類要特別多加小心。

規劃一個介面而不是實現一個介面。

(14)對公共介面中定義了大量訪問方法的類多加小心。大量訪問方法意味著相關資料和行為沒有集中存放。

(15)對包含太多互不溝通的行為的類多加小心。

這個問題的另一表現是在你的應用程式中的類的公有介面中建立了很多的get和set函式。

(16)在由同用戶介面互動的面向物件模型構成的應用程式中，模型不應該依賴於介面，介面則應當依賴於模型。

(17)儘可能地按照現實世界建模(我們常常為了遵守系統功能分佈原則、避免全能類原則以及集中放置相關資料和行為的原則而違背這條原則) 。

(18)從你的設計中去除不需要的類。

一般來說，我們會把這個類降級成一個屬性。

(19)去除系統外的類。

系統外的類的特點是，抽象地看它們只往系統領域傳送訊息但並不接受系統領域內其他類發出的訊息。 

(20)不要把操作變成類。質疑任何名字是動詞或者派生自動詞的類，特別是只有一個有意義行為的類。考慮一下那個有意義的行為是否應當遷移到已經存在或者尚未發現的某個類中。

(21)我們在建立應用程式的分析模型時常常引入代理類。在設計階段，我們常會發現很多代理沒有用的，應當去除。

(22)儘量減少類的協作者的數量。

一個類用到的其他類的數目應當儘量少。 

(23)儘量減少類和協作者之間傳遞的訊息的數量。

(24)儘量減少類和協作者之間的協作量，也即：減少類和協作者之間傳遞的不同訊息的數量。

(25)儘量減少類的扇出，也即：減少類定義的訊息數和傳送的訊息數的乘積。

(26)如果類包含另一個類的物件，那麼包含類應當給被包含的物件傳送訊息。也即：包含關係總是意味著使用關係。

(27)類中定義的大多數方法都應當在大多數時間裡使用大多數資料成員。

(28)類包含的物件數目不應當超過開發者短期記憶的容量。這個數目常常是6。

當類包含多於6個數據成員時，可以把邏輯相關的資料成員劃分為一組，然後用一個新的包含類去包含這一組成員。 

(29)讓系統功能在窄而深的繼承體系中垂直分佈。

(30)在實現語義約束時，最好根據類定義來實現。這常常會導致類氾濫成災，在這種情況下，約束應當在類的行為中實現，通常是在建構函式中實現，但不是必須如此。

(31)在類的建構函式中實現語義約束時，把約束測試放在建構函式領域所允許的儘量深的包含層次中。

(32)約束所依賴的語義資訊如果經常改變，那麼最好放在一個集中式的第3方物件中。

(33)約束所依賴的語義資訊如果很少改變，那麼最好分佈在約束所涉及的各個類中。

(34)類必須知道它包含什麼，但是不能知道誰包含它。

(35)共享字面範圍(也就是被同一個類所包含)的物件相互之間不應當有使用關係。

(36)繼承只應被用來為特化層次結構建模。

(37)派生類必須知道基類，基類不應該知道關於它們的派生類的任何資訊。

(38)基類中的所有資料都應當是私有的，不要使用保護資料。

類的設計者永遠都不應該把類的使用者不需要的東西放在公有介面中。 

(39)在理論上，繼承層次體系應當深一點，越深越好。

(40)在實踐中，繼承層次體系的深度不應當超出一個普通人的短期記憶能力。一個廣為接受的深度值是6。

(41)所有的抽象類都應當是基類。

(42)所有的基類都應當是抽象類。

(43)把資料、行為和/或介面的共性儘可能地放到繼承層次體系的高階。

(44)如果兩個或更多個類共享公共資料(但沒有公共行為)，那麼應當把公共資料放在一個類中，每個共享這個資料的類都包含這個類。

(45)如果兩個或更多個類有共同的資料和行為(就是方法)，那麼這些類的每一個都應當從一個表示了這些資料和方法的公共基類繼承。

(46)如果兩個或更多個類共享公共介面(指的是訊息，而不是方法)，那麼只有他們需要被多型地使用時，他們才應當從一個公共基類繼承。

(47)對物件型別的顯示的分情況分析一般是錯誤的。在大多數這樣的情況下，設計者應當使用多型。

(48)對屬性值的顯示的分情況分析常常是錯誤的。類應當解耦合成一個繼承層次結構，每個屬性值都被變換成一個派生類。

(49)不要通過繼承關係來為類的動態語義建模。試圖用靜態語義關係來為動態語義建模會導致在執行時切換型別。

(50)不要把類的物件變成派生類。對任何只有一個例項的派生類都要多加小心。

(51)如果你覺得需要在執行時刻建立新的類，那麼退後一步以認清你要建立的是物件。現在，把這些物件概括成一個類。

(52)在派生類中用空方法(也就是什麼也不做的方法)來覆寫基類中的方法應當是非法的。

(53)不要把可選包含同對繼承的需要相混淆。把可選包含建模成繼承會帶來氾濫成災的類。

(54)在建立繼承層次時，試著建立可複用的框架，而不是可複用的元件。

(55)如果你在設計中使用了多重繼承，先假設你犯了錯誤。如果沒犯錯誤，你需要設法證明。

(56)只要在面向物件設計中用到了繼承，問自己兩個問題：(1)派生類是否是它繼承的那個東西的一個特殊型別？(2)基類是不是派生類的一部分？

(57)如果你在一個面向物件設計中發現了多重繼承關係，確保沒有哪個基類實際上是另一個基類的派生類。

(58)在面向物件設計中如果你需要在包含關係和關聯關係間作出選擇，請選擇包含關係。

(59)不要把全域性資料或全域性函式用於類的物件的薄記工作。應當使用類變數或類方法。

(60)面向物件設計者不應當讓物理設計準則來破壞他們的邏輯設計。但是，在對邏輯設計作出決策的過程中我們經常用到物理設計準則。  

(61)不要繞開公共介面去修改物件的狀態。