Bjarne Stroustrup 對C++程式員的忠告

C++之父Bjarne Stroustrup寫的《The C++ Programming Language (Special

Edition)》中各章後面的忠告。

第1章 致讀者
[1] 在編寫程式時，你是在為你針對某個問題的解決方案中的思想建立起一種具體

表示。讓程式的結構儘可能地直接反映這些思想：
    [a] 如果你能把“它”看成一個獨立的概念，就把它做成一個類。
    [b] 如果你能把“它”看成一個獨立地實體，就把它做成某個類的一個對象。
    [c] 如果兩個類有共同的介面，將此介面做成一個抽象類別。
    [d] 如果兩個類的實現有某些顯著的共同東西，靜這些共性做成一個基類。
    [e] 如果一個類是一種對象的容器，將它做成一個模板。
    [f] 如果一個函數實現對某容器的一個演算法，將它實現為對一族容器可用的模

板函數。
    [g] 如果一組類、模板等互相之間有邏輯關係，將它們放進一個名字空間力。
[2] 在你定義一個並不是實現某個像矩陣或複數這樣的數學對象的類時，或者定義

一個低層地類型如連結資料表的時候：
    [a] 不要使用全域資料（使用成員）。
    [b] 不要使用全域函數。
    [c] 不要使用公用資料成員。
    [d] 不要使用友元，除非為了避免[a]或[c]。
    [e] 不要在一個類裡面放“類型域”；採用虛函數。
    [f] 不要使用線上函數，除非座位效果顯著的最佳化。

第2章 C++概覽

[1] 不用害怕，一切都會隨著時間的推移而逐漸明朗起來。
[2] 你並不需要在知道了C++地所有細節之後才能寫出好的C++程式。
[3] 請特別關注程式設計技術，而不是各種語言特徵。

第3章 標準庫概念

[1] 不要像重新發明車輪那樣企圖做每件事；去使用庫。
[2] 不要相信奇蹟；要理解你的庫能做什麼，它們如何做，它們做時需要多大代價

。
[3] 當你遇到一個選擇時，應該優先選擇標準庫而不是其他的庫。
[4] 不要認為標準庫對於任何事情都是最理想的。
[5] 切記#include你所用到的功能的標頭檔。
[6] 記住，標準庫的功能定義在名字空間std中。
[7] 請用string，而不是char*。
[8] 如果懷疑，就用一個檢查區間範圍的向量。
[9] vector<T>、list<T>和map<key, value>都比T[]好。
[10] 如果要向一個容器中添加一個元素，用push_back()或back_insert()。
[11] 採用對vector的push_back()，而不是realloc()。
[12] 在main()中捕捉公用的異常。

第4章 類型和聲明

[1] 保持較小的範圍。
[2] 不要在一個範圍和它外圍的範圍裡採用同樣的名字。
[3] 在一個聲明中（只）聲明一個名字。
[4] 讓常用的和局部的名字比較短，讓不常用的和全域的名字比較長。
[5] 避免看起來類似的名字。
[6] 維持某種統一的命名風格。
[7] 仔細選擇名字，反映其意義而不是反映實現方式。
[8] 如果所用的內部類型表示某種可能變化的值，請用typdef為它定義一個有意義

的名字。
[9] 用typedef為類型定義同義字，用枚舉或類去定義新類型。
[10] 切記每個聲明中都必須描述一個類型（沒有隱式的int）。
[11] 避免有關字元值的不必要的假設。
[12] 避免有關整數大小的不必要假設。
[13] 避免有關浮點類型表示範圍的不必要假設。
[14] 優先使用普通的int而不是short int或者long int。
[15] 優先使用double而不是float或者long double。
[16] 優先使用普通的char而不是signed char或者unsigned char。
[17] 避免做出有關對象大小的不必要假設。
[18] 避免無符號算術。
[19] 應該帶著疑問去看待從signed到unsigned，或者從unsigned到singed的轉換。
[20] 應該帶著疑問去看待從浮點到整數的轉換。
[21] 應該帶著疑問其看待向較小類型的轉換，如將int轉換到char。

第5章 指標、數組和結構

[1] 避免非平凡的指標算術。
[2] 當心，不要超出函數的界限去寫。
[3] 盡量使用0而不是NULL。
[4] 盡量使用vector和valarrray而不是內部（C風格）的數組。
[5] 盡量使用string而不是以0結尾的char數組。
[6] 盡量少使用普通的引用參數。
[7] 避免void*，除了在某些低級代理。
[8] 避免在代碼中使用非平凡的文字量（“神秘的數”）。相反，應該定義和使用

各種符號常量。

第6章 運算式和語句

[1] 應盡量可能使用標準庫，而不是其他的庫和“手工打造的代碼”。
[2] 避免過於複雜的運算式。
[3] 如果對運算子的優先順序有疑問，加括弧。
[4] 避免顯式類型轉換。
[5] 若必須做顯式類型轉換，提倡使用特殊強制運算子，而不是C風格的強制。
[6] 只對定義良好的構造使用T(e)記法。
[7] 避免帶有無定義求值順序的運算式。
[8] 避免goto。
[9] 避免do語句。
[10] 在你已經有了去初始化某個變數的值之前，不要去聲明它。
[11] 式注釋簡潔、清晰、有意義。
[12] 保持一致的縮排編排風格。
[13] 傾向於去定義一個成員函數operator new()去取代全域的operator new()。
[14] 在讀輸入的時候，總應考慮病態形式的輸入。

第7章 函數

[1] 質疑那些非const的引用參數；如果你想要一個函數去修改其參數，請使用指標

或者傳回值。
[2] 當你需要儘可能減少參數複製時，應該使用const引用參數。
[3] 廣泛而一致地使用const。
[4] 避免宏。
[5] 避免不確定數目的參數。
[6] 不要返回局部變數的指標或者引用。
[7] 當一些函數對不同的類型執行概念上相同的工作時，請使用重載。
[8] 在各種整數上重載時，通過提供函數去消除常見的歧義性。
[9] 在考慮使用指向函數的指標時，請考慮虛函數或模板是不是更好的選擇。
[10] 如果你必須使用宏，請使用帶有許多大寫字母的醜陋的名字。

第8章 名字空間和異常

[1] 用名字空間表示邏輯結構。
[2] 將每個非局部的名字放入某個名字空間裡，除了main()之外。
[3] 名字空間的設計應該讓你能很方便地使用它，而又不會意外地訪問了其他的無

關名字空間。
[4] 避免對名字空間使用很短的名字。
[5] 如果需要，通過名字空間別名去緩和和長名字空間的影響。
[6] 避免給你的名字空間的使用者添加太大的記法負擔。
[7] 在定義名字空間的成員時使用namespace::member的形式。
[8] 只在轉換時，或者在局部範圍裡，才用using namespace。
[9] 利用異常去鬆弛“錯誤”處理代碼和正常處理代碼之間的聯絡。
[10] 採用使用者定義型別作為異常，不用內部類型。
[11] 當局部控制結構足以應付問題，不要使用異常。

第9章 源檔案和程式

[1] 利用標頭檔去表示介面和強調邏輯結構。
[2] 用#include將標頭檔包含到實現有關功能的源檔案裡。
[3] 不要在不同編譯模組裡定義具有同樣名字，意義類似但又不同的全域變數。
[4] 避免在標頭檔裡定義非inline函數。
[5] 只在全域範圍或名字空間裡使用#include。
[6] 只用#include包含完整的定義。
[7] 使用包含保護符。
[8] 用#include將C標頭檔包含到名字空間裡，以避免全域名字。
[9] 將標頭檔做成自給自足的。
[10] 區分使用者介面和實現介面。
[11] 區分一般使用者介面和專家使用者介面。
[12] 在有意向用於非C++程式組成部分的代碼中，應避免需要運行時初始化的非局

部對象。

第10章 類

[1] 用類表示概念。
[2] 只將public資料（struct）用在它實際殺過那僅僅時資料，而且對於這些資料

成員並不存在不變式的地方。
[3] 一個具體類型屬於最簡單的類。如果有用的話，就應該儘可能使用具體類型，

而不要採用更複雜的阿里，也不要用簡單的資料結構。
[4] 只將那些需要直接存取類的表示的函數作為成員函數。
[5] 採用名字空間，使類與其協助函數之間的關係更明確。
[6] 將那些不修改對象值的成員函數做成const成員函數。
[7] 將那些需要訪問類的表示，但無須針對特定對象調用的成員函數做成static成

員函數。
[8] 通過建構函式建立起類的不變式。
[9] 如果建構函式申請某種資源，解構函式就應該釋放一資源。
[10] 如果在一個類裡有指標成員，它就要有複製操作（包括複製建構函式和複製賦

值）。
[11] 如果在一個類裡有引用成員，它就可能需要有複製操作（包括複製建構函式和

複製賦值）。
[12] 如果一個類需要複製操作或解構函式，它多半還需要有建構函式、解構函式、

複製賦值函數和複製建構函式。
[13] 在複製賦值函數裡需要檢查自我賦值。
[14] 在寫複製建構函式時，請小心地複製每個需要複製的元素（當心預設的初始式

）。
[15] 在向某個類中添加新成員函數時，一定要仔細檢查，看是否存在需要更新的用

戶定義建構函式，以使它能夠初始化新成員。
[16] 在類聲明中需要定義整型常量時，請使用枚舉。
[17] 在構造全域的和名字空間的對象時，應避免順序依賴性。
[18] 用第一次開關去緩和順序依賴性問題。
[19] 請記住，臨時對象將在建立它們的那個完整運算式結束時銷毀。

第11章 運算子多載

[1] 定義運算子主要是為了模仿習慣使用方式。
[2] 對於大型運算對象，請使用const引用參數類型。
[3] 對於大型的結果，請考慮最佳化返回方式。
[4] 如果預設複製操作對一個類和合適，最好是直接用它。
[5] 如果預設複製操作對一個類不和合適，重新定義它，或者禁止它。
[6] 對於需要訪問表示的操作，優先考慮作為成員函數而不是作為非成員函數。
[7] 對於不訪問表示的操作，優先考慮作為非成員函數而不是作為成員函數。
[8] 用名字空間將協助函數與“它們的”類關聯起來。
[9] 對於對稱的運算子採用非成員函數。
[10] 用()作為多維陣列的下標。
[11] 將只有一個“大小參數”的建構函式做成explicit。
[12] 對於非特殊的使用，最好是用標準string而不是你自己的練習。
[13] 要注意引進隱式轉換的問題。
[14] 用成員函數表達那些需要左值作為其左運算對象的運算子。

第12章 衍生類別

[1] 避免類型域。
[2] 用指標和引用避免切割問題。
[3] 用抽象類別將設計的中心集中到提供清晰的介面方面。
[4] 用抽象類別是介面最小化。
[5] 用抽象類別從介面中排除實現細節。
[6] 用虛函數是新的實現能夠添加進來，又不會影響使用者代碼。
[7] 用抽象類別去儘可能減少使用者代碼的重新編譯。
[8] 用抽象類別是不同的實現能夠共存。
[9] 一個有虛函數的類應該有一個虛解構函式。
[10] 抽象類別通常不需要建構函式。
[11] 讓不同概念的表示也不同。

第13章 模板

[1] 用模板描述需要使用到許多參數類型上去的演算法。
[2] 用模板表述容器。
[3] 為指標的容器提供專門化，以減小代碼規模。
[4] 總是在專門化之前聲明模板的一般形式。
[5] 在專門化的使用之前先聲明它。
[6] 盡量減少模板定義對於執行個體化環境的依賴性。
[7] 定義你所聲明的每一個專門化。
[8] 考慮一個模板是否需要有針對C風格字串和數組的專門化。
[9] 用表述策略的對象進行參數化。
[10] 用專門化和重載為同一概念的針對不同類型的實現提供統一介面。
[11] 為簡單情況提供簡單介面，用重載和預設參數去表述不常見的情況。
[12] 在修改為通用模板之前，在具體執行個體上排除程式錯誤。
[13] 如果模板定義需要在其他編譯模組裡訪問，請記住寫export。
[14] 對大模板和帶有非平凡環境依賴性的模板，應採用分開編譯的方式。
[15] 用模板表示轉換，但要非常小心地定義這些轉換。
[16] 如果需要，用constraint()成員函數給模板的實參增加限制。
[17] 通過顯式執行個體化減少編譯和連線時間。
[18] 如果運行時的效率非常重要，那麼最好用模板而不是衍生類別。
[19] 如果增加各種變形而又不重新編譯是很重要的，最好用衍生類別而不是模板。
[20] 如果無法定義公用的基類，最好用模板而不是衍生類別。
[21] 當有相容性約束的內部類型和結構非常重要時，最好用模板而不是衍生類別。

第14章 異常處理

[1] 用異常做錯誤處理。
[2] 當更局部的控制機構足以應付時，不要使用異常。
[3] 採用“資源申請即初始化”技術去管理資源。
[4] 並不是美國程式都要求具有異常時的安全性。
[5] 才用“資源申請即初始化”技術和異常處理器去維持不變式。
[6] 盡量少用try塊，用“資源申請即初始化”技術，而不是顯式的處理器代碼。
[7] 並不是美國函數都需要處理每個可能的錯誤。
[8] 在建構函式裡通過拋出異常指明出現失敗。
[9] 在從賦值中拋出異常之前，式操作對象處於合法狀態。
[10] 避免從解構函式裡拋出異常。
[11] 讓main()捕捉並報告所有的異常。
[12] 使正常處理代碼和錯誤處理代碼相互分離。
[13] 在建構函式裡拋出異常之前，應保證釋放在此建構函式裡申請的所有資源。
[14] 使資源管理具有層次性。
[15] 對於主要介面使用異常描述。
[16] 當心通過new分配的記憶體在發生異常時沒有釋放，並由此而導致儲存的流失。
[17] 如果一函數可能拋出某個異常，就應該假定它一定會拋出這個異常。
[18] 不要假定所有異常都時由excepion類派生出來的。
[19] 庫不應該單方面終止程式。相反，應該拋出異常，讓調用者去做決定。
[20] 庫不應該產生面向終端使用者的錯誤資訊。相反，它應該拋出異常，讓調用者去

做決定。
[21] 在設計的前期開發出一種錯誤處理策略。

第15章 類階層

[1] 利用常規的多重繼承表述特徵的合并。
[2] 利用多重繼承完成實現細節與介面分離。
[3] 用virtual基類表達在類階層裡對某些類（不是全部類）共同的東西。
[4] 避免顯式的類型轉換（強制）。
[5] 在不可避免地需要漫遊類階層的地方，使用dynamic_cast。
[6] 盡量使用dynamic_cast而不是typeid。
[7] 盡量使用private而不是protected。
[8] 不要聲明protected資料成員。
[9] 如果某個類定義了operator delete()，它也應該有虛解構函式。
[10] 在構造和析構期間不要調用虛函數。
[11] 盡量少用為解析成員名而寫的顯式限定詞，最好時在覆蓋函數裡用它。

第16章 庫組織和容器

[1] 利用標準庫功能，以維持可移植性。
[2] 決不要另行定義標準庫的功能。
[3] 決不要認為標準庫比什麼都好。
[4] 在定義一種新功能時，應考慮它是否能納入標準庫所提供的架構中。
[5] 記住標準庫功能都定義在名字空間std裡。
[6] 通過包含保准卡標頭檔聲明其功能，不要自己另行顯式聲明。
[7] 利用後續抽象的優點。
[8] 避免肥大的介面。
[9] 與自己寫按照反向順序的顯式迴圈相比，最好是寫利用反向迭代器的演算法。
[10] 用base()從reverse_iterator抽取出iterator。
[11] 通過引用傳遞容器。
[12] 用迭代器類型，如list<char>::iterator，而不要採用索引容器元素的指標。
[13] 在不需要修改容器元素時，使用const迭代器。
[14] 如果希望檢查存取範圍，請（直接或間接）使用at()。
[15] 多用容器和push_back()或resize()，少用數組和realloc().
[16] vector改變大小之後，不要使用指向其中的迭代器。
[17] 利用reserve()避免使迭代器非法。
[18] 在需要的時候，reserve()可以使執行情況更容易預期。

第17章 標準庫容器

[1] 如果要用容器，首先考慮用vector。
[2] 瞭解你經常使用的每個操作的代價（複雜性，大O度量）。
[3] 容器的介面、實現和表示使不同的概念，不要混淆。
[4] 你可以依據多種不同準則去排序和搜尋。
[5] 不要用C風格的字串作為關鍵碼，除非你提供了一種適當的比較準則。
[6] 你可以定義這樣的比較準則，使等價的但是不相同的關鍵碼值對應到同一個關

鍵碼。
[7] 在插入和刪除元素時，最好時使用序列末端的操作（back操作）。
[8] 當你需要在容器的前端或中間做許多插入和刪除時，請用list。
[9] 當你主要通過關鍵碼訪問元素時，請用map或multimap。
[10] 盡量用最小的操作集合，以取得最大的靈活性。
[11] 如果要保持元素的順序性，選用map而不是hash_map。
[12] 如果尋找速度極其重要，選hash_map而不是map。
[13] 如果無法對元素定義小於操作時，選hash_map而不是map。
[14] 當你需要檢查某個關鍵碼是否在關聯容器裡的時候，用find()。
[15] 用equal_range()在關聯容器裡找出所有具有給定關鍵碼的所有元素。
[16] 當具有同樣關鍵碼的多個值需要保持順序時，用multimap。
[17] 當關鍵碼本身就是你需要儲存的值時，用set或multiset。

第18章 演算法和函數對象

[1] 多用演算法，少用迴圈。
[2] 在寫迴圈時，考慮是否能將它表述為一個通用的演算法。
[3] 常規性地重溫演算法集合，看卡是不是能將新應用變得更明晰。
[4] 保證一對迭代器參數確實表述了一個序列。
[5] 設計時應該讓使用最頻繁的操作時簡單而安全的。
[6] 吧測試表述成能夠作為謂詞使用的形式。
[7] 切記謂詞是函數和對象，不是類型。
[8] 你可以用約束器從二元謂詞做出一元謂詞。
[9] 利用mem_fun()和mem_fun_ref()將演算法應用於容器。
[10] 當你需要將一個參數約束到一個函數上時，用ptr_fun()。
[11] 切記srrcmp()用0表示“相等”，與==不同。
[12] 僅在沒有更特殊的演算法時，才使用for_each()和tranform()。
[13] 利用謂詞，以便能一各種比較準則和相等準則使用演算法。
[14] 利用謂詞和其他函數對象，以使標準演算法能用於表示範圍廣泛的意義。
[15] 運算子<和==在指標上的預設意義很少適用於標準演算法。
[16] 演算法並不直接為它們的參數序列增加或減少元素。
[17] 應保證用於同一個序列的小於和相等謂詞相互匹配。
[18] 有時排好序的序列用起來更有效且優雅。
[19] 僅為相容性而使用qsort()和bsearch()。

第19章 迭代器和分配器

[1] 在寫一個演算法時，設法確定需要用哪種迭代器才能提供可接受的效率，並（只

）使用這種迭代器所支援的操作符去表述演算法。
[2] 當給定的迭代器參數提供了多於演算法所需 的最小支援時，請通過重載為該演算法

提供效率更高的實現。
[3] 利用istream_traits為不同迭代器類別描述適當的演算法。
[4] 記住在istream_iterator和ostream_iterator的訪問之前使用++。
[5] 用插入器避免容器溢出。
[6] 在排錯時使用額外的檢查，後面只在必須時才刪除這些檢查。
[7] 多用++p，少用p++。
[8] 使用未初始化的儲存去改善那些擴充資料結構的演算法效能。
[9] 使用臨時緩衝區去改善需要臨時資料結構的演算法的效能。
[10] 在寫自己的分配器之前三思。
[11] 避免malloc()、free()、realloc()等。
[12] 你可以通過為rebind所用的技術去類比對模板的typedef。

第20章 串

[1] 盡量使用string操作，少用C風格字串函數。
[2] 用string作為變數或者成員，不作為基類。
[3] 你可以將string作為參數值或者傳回值，讓系統去關心儲存管理問題。
[4] 當你希望做範圍檢查時，請用at()而不是迭代器或者[]。
[5] 當你希望最佳化速度時，請用迭代器或[]而不是at()。
[6] 直接或者間接地使用substr()去讀字子串，用replace()去寫子串。
[7] 用find()操作在string裡確定值的位置（而不是寫一個顯式的迴圈）。
[8] 在你需要高效率地添加字元時，請在string的後面附加。
[9] 在沒有極端時間要求情況下用string作為字元輸入的目標。
[10] 用string::npos表示“sring的剩餘部分”。
[11] 如果必要，就採用低級操作去實現極度頻繁使用的strng（而不是到處用低級

資料結構）。
[12] 如果你使用string，請在某些地方捕捉length_error和out_of_rang異常、
[13] 小心，不要將帶值0的char*傳遞給字串函數。
[14] 只是到必須做的時候，（再）用c_str()產生string的C風格表示。
[15] 當你需要知道字串的類別時，用isalpha()、isdigit()等函數，不要自己去

寫對字元值的檢測。

第21章 流

[1] 在為使用者定義型別的值定義<<和>>時，應該採用意義清晰的本文表達形式。
[2] 在列印包含低優先順序運算子的運算式時需要用括弧。
[3] 在添加新的<<和>>運算子時，你不必修改istream或ostream。
[4] 你可以定義函數，時其能基於第二個（或更後面的）參數，具有像virtual函數

那樣的行為。
[5] 切記，按預設約定>>跳過所有空格。
[6] 使用低級輸入函數（如get()和read()）主要是為了實現進階輸入函數。
[7] 在使用get()、getline()和read()時留心其終止準則。
[8] 在控制I/O時，盡量採用操控符，少用狀態標誌。
[9] （只）用異常去捕捉罕見的I/O錯誤。
[10] 連接用於互動式I/O的流。
[11] 使用哨位將許多函數的入口和出口代碼集中到一個地方。
[12] 在無參數操控符最後不要寫括弧。
[13] 使用標準操控符式應記住寫#include <iomanip>。
[14] 你可以通過定義一個簡單函數對象得到三元運算子的效果（和效率）。
[15] 切記，width描述只應用於隨後的一個I/O操作。
[16] 切記precision描述只對所後所的浮點數輸出操作有效。
[17] 用字串流做記憶體裡的格式化。
[18] 你可以描述一個檔案流的模式。
[19] 在擴充I/O系統時，應該清楚地區分格式化（iostream）和緩衝（streambuf）

。
[20] 將傳輸值的非標準方式實現為流緩衝。
[21] 將格式化值的非標準方式實現為流操作。
[22] 你可以利用一對函數隔離和封裝其對使用者定義代碼的調用。
[23] 你可以在讀入之前用in_avail()去確定輸入操作是否會被阻塞。
[24] 劃分清楚需要高效的簡單操作和實現某種策略的操作（將前者做成inline，將

後者做成virtual）。
[25] 用locale將“文化差異”局部化。
[26] 用sync_with_stdio(x)去混合C風格和C++風格的I/O，或者離解C風格和C++風

格的I/O。
[27] 當心C風格I/O的類型錯誤。

第22章 數值

[1] 數值問題常常和微妙。如果你對數值問題的數學方面不是100%有把握，請去找

專家或者做實驗。
[2] 用numberic_limits去確定內部類型的性質。
[3] 為使用者定義的標量類型描述numberic_limits。
[4] 如果運行時效率比對於操作和元素的靈活性更重要的話，那麼請用valarray去

做數值計算。
[5] 用切割表述在數組的一部分上的操作，而不是用迴圈。
[6] 利用組合器，通過清除臨時量和更好的演算法來獲得效率。
[7] 用std::complex做複數算術。
[8] 你可以把使用complex類的老代碼通過一個typedef轉為用str::complex模板。
[9] 在寫迴圈從一個表出發計算某個值之前，先考慮一下accumulate()、

inner_produce()、partial_sum()和adjacent_difference()。
[10] 最好使用具有特定分布的隨機數，少直接用rand()。
[11] 注意是你的隨機數充分隨機。

第23章 開發和設計

[1] 知道你試圖達到什麼目的。
[2] 心中牢記軟體開發是一項人的活動。
[3] 用類比來證明是有意的欺騙。
[4] 保持一個特定的實實在在的目標。
[5] 不要試圖用技術方式去解決社會問題。
[6] 在設計和對待人員方面都應該有長期考慮。
[7] 對於什麼程式在編碼之前先行設計是有意義的，在程式規模上並沒有下限。
[8] 設計過程應鼓勵反饋。
[9] 不要將做事情都當做取得了進展。
[10] 不要推廣到超出了所需要的、你已有直接經驗的和已經測試過的東西。
[11] 將概念表述為類。
[12] 系統裡也存在一些不應該用類表述的性質。
[13] 將概念間的層次關係用類階層表示。
[14] 主動到應用和實現中去尋找概念間的共性，將由此得到的一般性概念表示為基

類。
[15] 在其他領域中的分類方式未必適合作為應用中的繼承模型的分類方式。
[16] 基於行為和不變式設計類階層。
[17] 考慮用例。
[18] 考慮用CRC卡。
[19] 用現存系統作為模型、靈感的源泉和出發點。
[20] 意識到視覺圖形工程的重要性。
[21] 在原型成為負擔時就拋棄它。
[22] 為變化而設計，將注意力集中到靈活性、可擴充性、可移植性和重用。
[23] 將注意力集中到組件設計。
[24] 讓每個介面代表在一個抽象層次中的一個概念。
[25] 面向變化進行設計，以求得穩定性。
[26] 通過將廣泛頻繁使用的介面做得最小、最一般和抽象來使設計穩定。
[27] 保持儘可能小，不為“特殊需要”增加新特徵。
[28] 總考慮類的其他表示方式。如果不可能有其他方式，這個類可能就沒有代表某

個清晰的概念。
[29] 反覆評審、精化設計和實現。
[30] 採用那些能用於調試，用於分析問題、設計和實現的最好工具。
[31] 儘早、儘可能頻繁地進行實驗、分析和測試。
[32] 不要忘記效率。
[33] 保持某種適合項目規模的規範性水平。
[34] 保證有人負責項目的整體設計。
[35] 為可重用組件做文檔、推介和提供支援。
[36] 將目標與細節一起寫進文檔裡。
[37] 將為新開發人員提供的教許材料作為文檔的一部分。
[38] 鼓勵設計、庫和類的重用，並給予回報。

第24章 設計和編程

[1] 應該向資料抽象和物件導向設計的方向發展。
[2] （僅僅）根據需要去使用C++的特徵和技術。
[3] 設計應與編程風格相互匹配。
[4] 將類/概念作為設計中最基本的關注點，而不是功能/處理。
[5] 用類表示概念。
[6] 用繼承（僅僅）表示概念間的階層關係。
[7] 利用應用程式層靜態類型的方式給出有關介面的更強的保證。
[8] 使用程式產生器和直接介面操作工具去完成定義良好的工作。
[9] 不要去使用那些與任何通用程式設計語言之間都沒有清晰介面的程式產生器或

者直接介面操作工具。
[10] 儲存不同層次的抽象相互分離。
[11] 關注組件設計。
[12] 保證虛函數有定義良好的意義，每個覆蓋函數都實現預期行為。
[13] 公用介面表示的是“是一個”關係。
[14] 成員表示的是“有一個”關係。
[15] 在表示簡單包容時最好用直接成員，不用指向單獨分配的對象的指標。
[16] 設法保證使用依賴關係為易理解的，儘可能不出現迴圈，而且最小。
[17] 對於所有的類，定義好不變式。
[18] 顯式地將前條件、後條件和其他斷言表述為斷言（可能使用Assert()）。
[19] 定義的介面應該只暴露初儘可能少的資訊。
[20] 儘可能減少一個介面對其他介面的依賴性。
[21] 保持介面為強型別的。
[22] 利用應用程式層的類型來表述介面。
[23] 將介面表述得使請求可以傳遞給遠程得伺服器。
[24] 避免肥大的介面。
[25] 儘可能地使用private資料和成員函數。
[26] 用protected/private區分開衍生類別的設計者與一般使用者間的不同需要。
[27] 使用模板去做通用型程式設計。
[28] 使用模板去做演算法策略的參數化。
[29] 如果需要在編譯時間做類型解析，情使用模板。
[30] 如果需要在運行時做類型解析，請使用階層。

第25章 類的作用

[1] 應該對一個類的使用方式做出有意識的決策（作為設計師或者作為使用者）。
[2] 應注意到涉及不同種類的類之間的權衡問題。
[3] 用具體類型去表示簡單的獨立概念。
[4] 用具體類型去表示那些最佳效果及其關鍵的概念。
[5] 不要從具體類派生。
[6] 用抽象類別去表示那些對象的表示可能變化的介面。
[7] 用抽象類別去表示那些可能出現多種對象表示共存情況的介面。
[8] 用抽象類別去表示現存類型的新介面。
[9] 當類似概念共用許多實現細節時，應該使用結點類。
[10] 用結點類去逐步擴充一個實現。
[11] 用運行時類型識別從對象擷取介面。
[12] 用類去表示具有與之關聯的狀態資訊的動作。
[13] 用類去表示需要儲存、傳遞或者順延強制的動作。
[14] 利用介面類去為某種新的用法而調整一個類（不修改這個類）。
[15] 利用介面類增加檢查。
[16] 利用控制代碼去避免直接使用指標和引用。
[17] 利用控制代碼去管理共用的表示。
[18] 在那些能預先定義控制結構的應用領域中使用應用程式框架。