object-oriented design heuristics /arthur j.riel
ood啟思錄/(美
)里爾（
riel, a. j.
）著，鮑志雲譯
－北京：人民郵電出版社，
2004.7
第二章 類和物件：物件導向范型的建材
經驗原則
2.1所有資料都應當隱藏在它所在的類內部。
經驗原則
2.2類的使用者必須依賴類的公有介面，但類不能依賴它的使用者。
經驗原則
2.3儘量減少類的協議中的訊息。
經驗原則
2.4實現所有類都理解的最基本公用介面［例如：拷貝操作（深拷貝與淺拷貝）、相等性判斷、正確輸出內容、從
ascii
描述解析等等］
經驗原則
2.5不要把實現細節（例如放置共用**的私有函式）放到類的公有介面中。
經驗原則
2.6不要以使用者無法使用或不敢興趣的東西汙染類的公有介面。
經驗原則
2.7類之間應該零耦合，或者只有匯出耦合關係。也即，乙個類要麼同另乙個類毫無關係，要麼只使用另乙個類的公有介面中的操作。
經驗原則
2.8類應當只表示乙個關鍵抽象。
經驗原則
2.9把相關的資料和行為集中放置。
經驗原則
2.10
把不相關的資訊放在另乙個類中（也即：互不溝通的行為）。
經驗原則
2.11
確保你為之建模的抽象概念是類，而不只是物件扮演的角色。
第三章 應用程式布局：面向動作與物件導向
經驗原則
3.1在水平方向上盡可能統一地分布系統功能，也即：按照設計，頂層類應當統一地共享工作。
經驗原則
3.2在你的系統中不要建立全能類
/物件。對名字包含
driver
、manager
、system
、subsystem
的類要特別多加小心。
經驗原則
3.3對公共介面中定義了大量訪問方法的類要多加小心。大量訪問方法意味著相關資料和行為沒有集中存放。
經驗原則
3.4對包含太多互不溝通的行為的類要多加小心。互不溝通的行為是指在類的資料成員的乙個真子集上進行操作的方法。全能類經常有很多互不溝通的行為。
經驗原則
3.5在由同使用者介面互動的物件導向模型構成的應用程式中，模型不應該依賴於介面，介面則應當依賴於模型。
經驗原則
3.6盡可能地按照現實世界建模（我們常常為了遵守系統功能分布原則、避免全能類原則以及集中放置相關資料和行為的原則而違背這條原則）。
經驗原則
3.7從你的設計中去除不需要的類。
經驗原則
3.8去除系統外的類。
經驗原則
3.9不要把操作變成類。質疑任何名字是動詞或者派生自動詞的類，特別是只有乙個有意義行為（即：不考慮訪問和列印成員的行為）的類。考慮一下那個有意義的行為是否應當遷移到已經存在或者尚未發現的某個類中。
經驗原則
3.10
我們在建立應用程式地分析模型時常常引入**類。在設計階段，我們常會發現很多**是沒有用的，應當去除。
第四章 類和物件的關係
經驗原則
4.1儘量減少類的協作者的數量。
經驗原則
4.2儘量減少類的協作者之間傳遞的訊息的數量。
經驗原則
4.3儘量減少類的協作者之間的協作量，即：減少類和協作者之間傳遞的不同訊息的數量。
經驗原則
4.4儘量減少類的扇出，也即：減少類定義的訊息數和傳送的訊息數的乘積。
經驗原則
4.5如果類包含另乙個類的物件，那麼包含類應該給被包含的物件傳送訊息。即：包含關係總是意味著使用關係。
經驗原則
4.6類中定義的大多數方法都應當在大多數時間裡使用大多數資料成員。
經驗原則
4.7類包含的物件書目不應當超過開發者短期記憶的容量。這個數目常常是6。
經驗原則
4.8讓系統功能在窄而深的繼承體系中垂直分布。
經驗原則
4.9實現語義約束時，最好根據類定義來實現。這常常會導致類氾濫成災，在這種情況下約束應當在類的行為中實現，通常是在建構函式中實現，但不是必須如此。
經驗原則
4.10
當在類的建構函式中實現語義約束時，把約束測試放在建構函式領域所允許的盡量深的包含層次中。
經驗原則
4.11
約束所依賴的語義資訊如果經常改變，那麼最好放在乙個集中式的第三方物件中。
經驗原則
4.12
約束所依賴的語義資訊如果很少改變，那麼最好分布在約束所涉及的各個類中。
經驗原則
4.13
類必須知道它包含什麼，但是不能知道誰包含它。
經驗原則
4.14
共享字面範圍（也就是被同乙個類所包含）的物件相互之間不應當有使用關係。
第五章 繼承關係
經驗原則
5.1繼承只應被用來為特化層次結構建模。
經驗原則
5.2派生類必須知道他們的基類，基類不應到知道關於它們的派生類的任何資訊。
經驗原則
5.3基類中的所有資料都應當是私有的，不要使用保護資料。
經驗原則
5.4在理論上，繼承層次體系應當深一點，越深越好。
經驗原則
5.5在實踐中，繼承層次體系地深度不應當超出乙個普通人的短期記憶能力。乙個廣為接受的深度值是6。
經驗原則
5.6所有的抽象類都應當是基類。
經驗原則
5.7所有的基類都應當是抽象類。
經驗原則
5.8把資料、行為和（或）介面的共性盡可能地放到繼承層次體系的高階。
經驗原則
5.9如果兩個或更多個類共享公共資料（但沒有公共行為），那麼應當把公共資料放在乙個類中，每個共享這些資料的類都包含這個類。
經驗原則
5.10
如果兩個或更多個類有共同的資料或行為（就是方法），那麼這些類地每乙個都應當從乙個表示了這些資料和方法的公共基類繼承。
經驗原則
5.11
如果兩個或更多個類共享公共介面（指的是訊息，而不是方法），那麼只有它們需要被多型地使用時，它們才應當從乙個公共基類繼承。
經驗原則
5.12
對物件型別的顯式地分情況分析一般是錯誤的。在大多數這樣的情況下，設計者應當使用多型。
經驗原則
5.13
對屬性值的顯式地分情況分析常常是錯誤的。類應當解耦合成乙個繼承層次結構，每個屬性值都被變換成乙個派生類。
經驗原則
5.14
不要通過繼承關係來為類的動態語義建模。試圖用靜態語義關係來為動態語義建模會導致在執行時切換型別。
經驗原則
5.15
不要把類的物件變成派生類。對任何只有乙個例項的派生類都要多加小心。
經驗原則
5.16
如果你覺得需要在執行時建立新的類，那麼退後一步以認清你要建立的是物件。現在，把這些物件概括成乙個類。
經驗原則
5.17
在派生類中用空方法（也就是什麼都不做的方法）來覆寫基類中的方法應當是非法的。
經驗原則
5.18
不要可選包含同對繼承的需要相混淆。把可選包含建模成繼承會帶來氾濫成災的類。
經驗原則
5.19
在建立繼承層次時，試著建立可復用的框架，而不是可復用的元件。
第六章 多重繼承
經驗原則
6.1如果你在設計中用到了多重繼承，先假設你犯了錯誤。如果沒犯錯誤，你需要證明。
經驗原則
6.2只要在物件導向設計中用到了繼承，問自己兩個問題：
1.派生類是否是它繼承的那個東西的乙個特殊型別？
2.基類是不是派生類的一部分？
經驗原則
6.3如果你在乙個物件導向設計中發現了多重繼承關係，確保沒有哪個基類實際上是另乙個基類的派生類。
第七章 關聯關係
經驗原則
7.1在物件導向設計中如果你需要在包含關係和關聯關係間做出選擇，請選擇包含關係。
第八章 與特定類相關的資料及行為
經驗原則
8.1不要把全域性資料或全域性函式用於類的物件的簿記工作，應當使用類變數或者類方法。
第九章 物件導向物理設計
經驗原則
9.1物件導向設計者不應當讓物理設計準則來破壞他們的邏輯設計，但是，在對邏輯設計做出決策的過程中我們經常用到物理設計準則。
經驗原則
9.2不要繞開公有介面去修改物件的狀態。
c++
中的記憶體洩漏
洩漏1
在類的建構函式和析構函式中沒有匹配地呼叫
new和
delete
函式洩漏
2沒有正確地清除巢狀的物件指標洩漏3
在釋放物件陣列時在
delete
中沒有使用方括號洩漏4
指向物件的指標陣列不等同於物件陣列洩漏5
缺少拷貝建構函式洩漏6
缺少過載賦值運算子洩漏7
關於nonmodifying
運算子過載的常見迷思洩漏8
沒有將基類的析構函式定義為虛函式
《OOD啟思錄》 書摘精要
p7 本身沒什麼意義，從 提煉出來的無形的設計才是真正有價值的 的尺寸 或者說粒度 和它的靈活性成反比 p13 經驗原則 2.1 所有資料都應該隱藏在它所在的類內部 p15 經驗原則 2.2 類的使用者必須依賴類的公有介面，但類不能依賴它的使用者 p16 經驗原則 2.3 儘量減少類的協議中的訊息 ...
《OOD啟思錄》 第1章1 4節迭代模型
1.4 迭代模型 ood啟思錄 軟體開發的迭代模型看上去和瀑布模型差不多，區別只在於迭代模型允許開發者沿專案流程往返 見圖1.2 如果我們在為系統的某個部分編寫 時發現了乙個設計缺陷，我們可以回到設計階段來分析並改正它。或者，如果我們在測試系統的一部分時發現了新的系統需求，我們可以回到分析階段來修正...
OOD 啟思錄 61條物件導向設計的經驗原則
你不必嚴格遵守這些原則，違背它們也不會被處以宗教刑罰。但你應當把這些原則看成警鈴，若違背了其中的一條，那麼警鈴就會響起 arthur j.riel 1 所有資料都應該隱藏在所在的類的內部。2 類的使用者必須依賴類的共有介面，但類不能依賴它的使用者。3 儘量減少類的協議中的訊息。4 實現所有類都理解的...