《OOD啟思錄》 書摘精要

**本身沒什麼意義，從**提煉出來的無形的設計才是真正有價值的；

**的尺寸(或者說粒度)和它的靈活性成反比；

(p13) 經驗原則 2.1 —— 所有資料都應該隱藏在它所在的類內部；

(p15) 經驗原則 2.2 —— 類的使用者必須依賴類的公有介面，但類不能依賴它的使用者；

(p16) 經驗原則 2.3 —— 儘量減少類的協議中的訊息；

(p16) 經驗原則 2.4 —— 實現所有類都理解的最基本公有介面[例如，拷貝操作(深拷貝與淺拷貝)、相等性判斷、正確輸出內容、從ascii描述解析等等]；

(p17) 經驗原則 2.5 —— 不要把實現細節(例如放置共用**的私有函式)放到類的公有介面中；

(p17) 經驗原則 2.6 —— 不要以使用者無法使用或不感興趣的東西擾亂類的公有介面；

(p18) 經驗原則 2.7 —— 類之間應該零耦合，或者只有匯出耦合關係。也即，乙個類要麼同另乙個類毫無關係，要麼只使用另乙個類的公有介面中的操作；

(p19) 經驗原則 2.8 —— 類應當只表示乙個關鍵抽象；

(p19) 經驗原則 2.9 —— 把相關的資料和行為集中放置；

(p19) 經驗原則 2.10 —— 把不相關的資訊放在另乙個類中(也即：互不溝通的行為)；

(p23) 經驗原則 2.11 —— 確保你為之建模的抽象概念是類，而不只是物件扮演的角色；

(p30) 經驗原則 3.1 —— 在水平方向上盡可能統一地分布系統功能，也即：按照設計，頂層類應當統一地共享工作；

(p30) 經驗原則 3.2 —— 在你的系統中不要建立全能類/物件。對名字包含driver、manager、system、subsystem的類要特別多加小心；

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

(p31) 經驗原則 3.4 —— 對包含太多互不溝通的行為的類多加小心。互不溝通的行為是指在類的資料成員的乙個真子集上進行操作的方法。全能類經常有很多互不溝通的行為；

(p33) 經驗原則 3.5 —— 在由同使用者介面互動的物件導向模型構成的應用程式中，模型不應該依賴於介面，介面則應當依賴於模型；

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

(p38) 經驗原則 3.7 —— 從你的設計中去除不需要的類；

(p39) 經驗原則 3.8 —— 去除系統外的類；

(p40) 經驗原則 3.9 —— 不要把操作變成類。質疑任何名字是動詞或者派生自動詞的類，特別是只有乙個有意義行為(即：不考慮訪問和列印成員的行為)的類。考慮一下那個有意義的行為是否應當遷移到已經存在或者尚未發現的某個類中；

(p43) 經驗原則 3.10 —— 我們在建立應用程式的分析模型時常常引入**類。在設計階段，我們常會發現很多**是沒有用的，應當去除；

(p52) 經驗原則 4.1 —— 儘量減少類的協作者的數量；

(p55) 經驗原則 4.2 —— 儘量減少類和協作者之間傳遞的訊息的數量；

(p55) 經驗原則 4.3 —— 儘量減少類和協作者之間的協作量，也即：減少類和協作者之間傳遞的不同訊息的數量；

(p55) 經驗原則 4.4 —— 盡量減小類的扇出，也即：減少類定義的訊息數和傳送的訊息數的乘積；

(p55) 經驗原則 4.5 —— 如果類包含另乙個類的物件，那麼包含類應當給被包含的物件傳送訊息。也即：包含關係總是意味著使用關係；

(p57) 經驗原則 4.6 —— 類中定義的大多數方法都應當在大多數時間裡使用大多數資料成員；

(p57) 經驗原則 4.7 —— 類包含的物件數目不應當超過開發者短期記憶的容量。這個數目常常是6；

(p58) 經驗原則 4.8 —— 讓系統功能在窄而深的繼承體系中垂直分布；

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

(p60) 經驗原則 4.10 —— 當在類的建構函式中實現語義約束時，把約束測試放在建構函式領域所允許的盡量深的包含層次中；

(p60) 經驗原則 4.11 —— 約束所依賴的語義資訊如果經常改變，那麼最好放在乙個集中式的第三方物件中；

(p60) 經驗原則 4.12 —— 約束所依賴的語義資訊如果很少改變，那麼最好分布在約束所涉及的各個類中；

(p61) 經驗原則 4.13 —— 類必須知道它包含什麼，但是不能知道誰包含它；

(p61) 經驗原則 4.14 —— 共享字面範圍(也就是被同乙個類所包含)的物件相互之間不應當有使用關係；

(p74) 經驗原則 5.1 —— 繼承只應被用來為特化層次結構建模；

(p74) 經驗原則 5.2 —— 派生類必須知道它們的基類，基類不應當知道關於它們的派生類的任何資訊；

(p75) 經驗原則 5.3 —— 基類中的所有資料都應當是私有的，不要使用保護資料；

(p77) 經驗原則 5.4 —— 在理論上，繼承層次體系應當深一點，越深越好；

(p77) 經驗原則 5.5 —— 在實踐中，繼承層次體系的深度不應當超出乙個普通人的短期記憶能力。乙個廣為接受的深度值是6；

(p81) 經驗原則 5.6 —— 所有的抽象類都應當是基類；

(p82) 經驗原則 5.7 —— 所有的基類都應當是抽象類；

(p85) 經驗原則 5.8 —— 把資料、行為和/或介面的共性盡可能地放到繼承層次體系的高階；

(p88) 經驗原則 5.9 —— 如果兩個或更多個類共享公共資料(但沒有公共行為)，那麼應當把公共資料放在乙個類中，每個共享這些資料的類都包含這個類；

(p89) 經驗原則 5.10 —— 如果兩個或更多個類有共同的資料和行為(就是方法)，那麼這些類的每乙個都應當從乙個表示了這些資料和方法的公共基類繼承；

(p89) 經驗原則 5.11 —— 如果兩個或更多個類共享公共介面(指的是訊息，而不是方法)，那麼只有它們需要被多型地使用時，它們才應當從乙個公共基類繼承；

(p89) 經驗原則 5.12 —— 對物件型別的顯式的分析情況分析一般是錯誤的。在大多數這樣的情況下，設計者應當使用多型；

(p96) 經驗原則 5.13 —— 對屬性值的顯式的分情況分析常常是錯誤的。類應當解耦合成乙個繼承層次結構，每個屬性值都被變換成乙個派生類；

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

(p99) 經驗原則 5.15 —— 不要把類的物件變成派生類。對任何只有乙個例項的派生類都要多加小心；

(p103) 經驗原則 5.16 —— 如果你覺得需要在執行時建立新的類，那麼退後一步以認清你要建立的是物件。現在，把這些物件概括成乙個類；

(p103) 經驗原則 5.17 —— 在派生類中用空方法(也就是什麼都不做的方法)來覆寫基類中的方法應當是非法的；

(p108) 經驗原則 5.18 —— 不要把可選包含同對繼承的需要相混淆。把可選包含建模成繼承會帶來氾濫成災的類；

(p112) 經驗原則 5.19 —— 在建立繼承層次時，試著建立可復用的框架，而不是可復用的元件；

(p120) 經驗原則 6.1 —— 如果你在設計中用到了多重繼承，先假設你犯了錯誤。如果沒犯錯誤，你需要設法證明；

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

(p122) 經驗原則 6.3 —— 如果你在乙個物件導向設計中發現了多重繼承關係，確保沒有哪個基類實際上是另乙個基類的派生類；

(p135) 經驗原則 7.1 —— 在物件導向設計中如果你需要在包含關係和關聯關係間做出選擇，請選擇包含關係；

(p140) 經驗原則 8.1 —— 不要把全域性資料或全域性函式用於類的物件的簿記工作。應當使用類變數或者類方法；

(p149) 經驗原則 9.1 —— 物件導向設計者不應當讓物理設計準則來破壞他們的邏輯設計。但是，在對邏輯設計做出決策的過程中我們經常用到物理設計準則；