第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] 在那些能預先定義控制結構的應用領域中使用應用框架。