《OOD啓思錄》 - 書摘精要

(P7)

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

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

(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 —— 面向對象設計者不應當讓物理設計準則來破壞他們的邏輯設計。但是，在對邏輯設計做出決策的過程中我們經常用到物理設計準則；

(P164) 經驗原則 9.2 —— 不要繞開公有接口去修改對象的狀態；