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

(1)所有數(shù)據(jù)都應該隱藏在所在的類的內部。

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

(3)盡量減少類的協(xié)議中的消息。

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

(5)不要把實現(xiàn)細節(jié)(例如放置共用代碼的私有函數(shù))放到類的公有接口中。
如果類的兩個方法有一段公共代碼，那么就可以創(chuàng)建一個防止這些公共代碼的私有函數(shù)。  

(6)不要以用戶無法使用或不感興趣的東西擾亂類的公有接口。

(7)類之間應該零耦合，或者只有導出耦合關系。也即，一個類要么同另一個類毫無關系，要么只使用另一個類的公有接口中的操作。

(8)類應該只表示一個關鍵抽象。
包中的所有類對于同一類性質的變化應該是共同封閉的。一個變化若對一個包影響，則將對包中的所有類產生影響，而對其他的包不造成任何影響 .  

(9)把相關的數(shù)據(jù)和行為集中放置。
設計者應當留意那些通過get之類操作從別的對象中獲取數(shù)據(jù)的對象。這種類型的行為暗示著這條經驗原則被違反了。  

(10)把不相關的信息放在另一個類中(也即：互不溝通的行為)。
朝著穩(wěn)定的方向進行依賴.  

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

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

(13)在你的系統(tǒng)中不要創(chuàng)建全能類/對象。對名字包含driver、manager、system、susystem的類要特別多加小心。
規(guī)劃一個接口而不是實現(xiàn)一個接口。  

(14)對公共接口中定義了大量訪問方法的類多加小心。大量訪問方法意味著相關數(shù)據(jù)和行為沒有集中存放。

(15)對包含太多互不溝通的行為的類多加小心。
這個問題的另一表現(xiàn)是在你的應用程序中的類的公有接口中創(chuàng)建了很多的get和set函數(shù)。  

(16)在由同用戶界面交互的面向對象模型構成的應用程序中，模型不應該依賴于界面，界面則應當依賴于模型。

(17)盡可能地按照現(xiàn)實世界建模(我們常常為了遵守系統(tǒng)功能分布原則、避免全能類原則以及集中放置相關數(shù)據(jù)和行為的原則而違背這條原則) 。

(18)從你的設計中去除不需要的類。
一般來說，我們會把這個類降級成一個屬性。  

(19)去除系統(tǒng)外的類。
系統(tǒng)外的類的特點是，抽象地看它們只往系統(tǒng)領域發(fā)送消息但并不接受系統(tǒng)領域內其他類發(fā)出的消息。  

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

(21)我們在創(chuàng)建應用程序的分析模型時常常引入代理類。在設計階段，我們常會發(fā)現(xiàn)很多代理沒有用的，應當去除。

(22)盡量減少類的協(xié)作者的數(shù)量。
一個類用到的其他類的數(shù)目應當盡量少。  

(23)盡量減少類和協(xié)作者之間傳遞的消息的數(shù)量。

(24)盡量減少類和協(xié)作者之間的協(xié)作量，也即：減少類和協(xié)作者之間傳遞的不同消息的數(shù)量。

(25)盡量減少類的扇出，也即：減少類定義的消息數(shù)和發(fā)送的消息數(shù)的乘積。

(26)如果類包含另一個類的對象，那么包含類應當給被包含的對象發(fā)送消息。也即：包含關系總是意味著使用關系。

(27)類中定義的大多數(shù)方法都應當在大多數(shù)時間里使用大多數(shù)數(shù)據(jù)成員。

(28)類包含的對象數(shù)目不應當超過開發(fā)者短期記憶的容量。這個數(shù)目常常是6。
當類包含多于6個數(shù)據(jù)成員時，可以把邏輯相關的數(shù)據(jù)成員劃分為一組，然后用一個新的包含類去包含這一組成員。  

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

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

(31)在類的構造函數(shù)中實現(xiàn)語義約束時，把約束測試放在構造函數(shù)領域所允許的盡量深的包含層次中。

(32)約束所依賴的語義信息如果經常改變，那么最好放在一個集中式的第3方對象中。

(33)約束所依賴的語義信息如果很少改變，那么最好分布在約束所涉及的各個類中。

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

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

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

(37)派生類必須知道基類，基類不應該知道關于它們的派生類的任何信息。

(38)