經驗原則總結
第2章    類和物件：面向物件範型的建材
1.  所以資料都應該隱藏在它所在的類內部。
2.  類的使用者必須依賴類的公有介面，但類不能依賴它的使用者
3.  儘量減少類的協議中的訊息
4.  實現所有類都理解的最基本公有介面[例如：拷貝操作（深拷貝與淺拷貝），相等性判斷，正確輸出內容，從ASCII描述解析等等]。
5.  不要把實現細節（例如放置公用程式碼的私有函式）放到類的公用介面中。
6.  不要以使用者無法使用或不感興趣的東西汙染的公有介面。
7.  類之間應該零偶合，或者匯出耦合關係。也即，一個類要麼同另一個類毫無關係，要麼只使用另一個類的公有介面中的操作。
8.  類應該只表示一個關鍵抽象
9.  把相關的資料和行為集中放置
10.  把不相關的資訊放在另一個類中（也即：互不溝通的行為）
11.  確保你為之建模的抽象概念是類，而不只是物件扮演的角色
第3章    應用程式佈局：面向動作與面向物件
1.  在水平方向上儘可能統一地分佈系統，也即：按照設計，頂層型別當統一地共享工作
2.  在你的系統中不要建立全能類/物件。對名字包含Driver,Manager,System,Subsystem的類要特別多加小心
3.  對公共介面中定義了大量訪問的類多加小心。大量訪問方法意味著相關資料和行為沒有集中存放
4.  對包含太多互不溝通的行為的類要多加小心。互不溝通的行為是指在類的資料成員的一個真子集上進行操作的方法。全能類經常有很多互不溝通的行為
5.  在由使用者介面互動的面向物件模型構成的應用程式中，模型不應該依賴介面，介面則應該依賴於模型
6.  儘可能地按照現實世界建模（我們常常為了遵守系統功能分佈原則，避免全能原則以及集中放置相關資料和行為的原則而違背這條原則）
7.  從你的設計中去除不需要的類
8.  去除系統外的類
9.  不要把操作變成類。質疑任何名字是洞子或者派生自動詞的類，特別是只有一個有意義行為（即：不考慮存取和列印成員的行為）的類。考慮一下那個有意義的行為為是否應該遷移到已經存在的或者尚未發行的某個類中。
10.  我們在建立應用程式的分析模型時常常引入代理類。在設計階段，我們常會發現很多代理是沒有用的。應該去除。
第4章    類和物件的關係
1.  儘量減少類的協作者的數量
2.  儘量減少類和協作者之間傳遞的訊息的數量
3.  儘量減少類和協作者之間的協作量，也即：減少類和協作者之間的傳遞的不同訊息的數量
4.  間量減少類的扇出，也即：減少類定義的訊息數和傳送的訊息數的乘積。
5.  如果類包含另一個一個類的物件，那麼包含類應該給被包含的物件傳送訊息，也即：包含關係總是意味著使用關係
6.  類中定義的大多數方法都應該在大多數時間裡使用大多數資料成員
7.  類包含的物件數目不應該超過開發者短期記憶的容量。這個數目常常是6
8.  讓系統功能在窄而深的繼承關係中垂直分佈
9.  實現語義約束時，最好根據類定義來實現。這個常常導致氾濫成災的類，在這種情況下，約束應當在類的行為中實現，通常是在建構函式中實現，但不是必須如此
10.  當在類的建構函式中實現語義約束時，把約測試放在建構函式領域所允許的儘量深的包含層次中
11.  約束所依賴的語義資訊如果經常發生改變，那麼最好分佈在約束所涉及的各個類中
12.  類必須知道它包含什麼，但是不能知道誰包含它
13.  約束所依賴的語義資訊如果經常改變，那麼最好放在一個集中式的第三個類中
14.  共享字面範圍（也就是被同一個類所包含）的物件相互之間不應當有使用關係
第5章    繼承關係
1.  繼承只應該被用來為特化層次結構建模
2.  派生類必須知道他們的基類，基類不應當知道關於他們的派生類的任何資訊
3.  基類中的所有資料都應當式私有的，不要使用保護資料
4.  在理論上，繼承層次體系應當深一點，越深越好
5.  在時間中，繼承層次體系的深度不應當超出一個普通人的短期記憶能力。一個廣為接受的深度是6
6.  所有的抽象類都應當是基類
7.  所有的基類都應該是抽象類
8.  把資料，行為和/或介面的共性儘可能的放在繼承層次體系的高階
9.  如果兩個或者更多的共享公共資料（但沒有公共行為），那麼應當把公共資料放在一個類中，每個共享這些資料的類都包含這個類
10.  如果兩個或更多類有共同的資料和行為（就是方法），那麼這些類的每一個都應該從一個表示了這些資料和方法的公共基類繼承
11.  如果兩個或更多共享公共介面（就是訊息，不是方法），那麼只有它們需要被多型的使用時，它們才應當從一個公共基類繼承
12.  對物件型別的顯式地分情況分析常常是錯誤的。在大多數這樣的情況下，設計者應當使用多型
13.  對物件型別的顯式地分情況分析常常是錯誤的。類應當解耦合成為一個繼承層次結構，每個屬性值都變換成為一個派生類
14.  不要通過繼承關係來為類的動態語義建摸。試圖用靜態語義關係來為動態語義建模會導致在執行時切換型別。
15.  不要把類的物件變成派生類。對任何只有一個例項的派生類都要多加小心
16.  如果你覺得需要在執行時建立新的類，那麼退後一步以認清你要建立的時物件。現在，把這些物件概括成一個類
17.  在派生類中用空方法（也就是什麼都不做的方法）來腹寫基類中的方法應當是非法的。
18.  不要把可選的包含同繼承的需要相混淆。把可選的包含建模成繼承會帶來氾濫成災的類
19.  在建立繼承層次的時，試圖建立可複用的框架，而不是可復的元件

第6章    多重繼承
1.  如果你在設計中用到了多重繼承，先假設你犯了錯誤。如果沒有犯錯誤，你需要設法證明它
2.  只要在面向物件的設計中用到了繼承，問自己兩個問題：
a)  派生類是否是它繼承的那個東西的一個特殊型別
b)  基類是不是派生類的一部分
3.  如果你在一個面向物件的設計中發現了多重繼承關係，確保沒有哪個基類實際上是另一個基類的派生類
第7章    關聯關係
1.  在面向物件的設計中如果你需要在你包含關係和關聯關係間做出選擇，請選擇包含關係。
第8章    與特定類相關的資料及行為
1.  不要把全域性資料或區域性函式用於類的物件的薄記工作。應當使用類變數或者類方法
第9章    面向物件物理設計
1.  面向物件設計者步應當讓物理設計準則來破壞他們的邏輯設計。但是，在對邏輯設計做出決策的過程中我們經常用到物理設計準則
2.  不要繞開公有介面取修改物件的狀態