(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)
不要繞開公共介面去修改物件的狀態
。
61條物件導向設計的經驗原則
你不必嚴格遵守這些原則，違背它們也不會被處以宗教刑罰。但你應當把這些原則看成警鈴，若違背了其中的一條，那麼警鈴就會響起。arthur j.riel 1 所有資料都應該隱藏在所在的類的內部。p13 2 類的使用者必須依賴類的共有介面，但類不能依賴它的使用者。p15 3 儘量減少類的協議中的訊息。p16...
61條物件導向設計的經驗原則
你不必嚴格遵守這些原則，違背它們也不會被處以宗教刑罰。但你應當把這些原則看成警鈴，若違背了其中的一條，那麼警鈴就會響起。arthur j.riel 1 所有資料都應該隱藏在所在的類的內部。p13 2 類的使用者必須依賴類的共有介面，但類不能依賴它的使用者。p15 3 儘量減少類的協議中的訊息。p16...
61條物件導向設計的經驗原則
你不必嚴格遵守這些原則，違背它們也不會被處以宗教刑罰。但你應當把這些原則看成警鈴，若違背了其中的一條，那麼警鈴就會響起。arthur j.riel 1 所有資料都應該隱藏在所在的類的內部。2 類的使用者必須依賴類的共有介面，但類不能依賴它的使用者。3 儘量減少類的協議中的訊息。4 實現所有類都理解的...