類應該短小，從這個意義上來說，類和函式有很多相似點，但衡量函式的「小」可以通過**行數，而衡量類的大小是通過「權責」。
類的名稱應當描述其權責，實際上，命名正是幫助判斷類的長度的第乙個手段，如果無法為某個類命以精確的名稱，這個類大概就太長了。如果類的命名越含混，不夠精確，該類越有可能擁有過多權責。
我們也應該能夠用大概25個單詞簡要描述乙個類，且不用「若」、「與」、「或者」、「但」等詞。記住，類應該簡單，權責單一。
類應該遵循單一許可權原則（srp）。但如果遵循此原則，就會產生數量巨大的類。許多開發者害怕數量巨大的短小單一目的的類會導致難以一目了然抓住全域性。他們認為，要搞清楚一件較大工作如何完成，就得在類與類之間找來找去。然而，有大量短小類的系統並不比有少量龐大類的系統擁有更多移動部件，其數量大致相等。問題是：你是想把工具歸置到有許多抽屜、每個抽屜中裝有定義和標記良好的元件的工具箱中呢，還是想要少數幾個能隨便把所有東西扔進去的抽屜？
再強調一下：系統應該由許多短小的類而不是少量巨大的類組成。每個小類封裝乙個權責，只有乙個修改的原因，並與少數其他類一起協同達成期望的系統行為。
管理大量小類的最有效辦法就是給類分抽象層次。而在修改的時候，要自頂向下閱讀，邏輯漸漸展現開來，不會在抽象層級較高的層面就陷入實現的細節中。
好的類應該是高內聚的。通常而言，方法操作的變數越多，就越黏取到類上。如果乙個類中的每個變數都被每個方法所使用，則該類具有最大的內聚性。一般來說，建立這種極大化內聚類是既不可取也不可能的;另一方面，我們希望內聚性保持在較高位置。內聚性高，意味著類中的方法和變數互相依賴、互相結合成乙個邏輯整體。
前面我們說過，函式應該保持短小，引數較少。我們應盡量將大函式拆分成小函式，將多引數減小成少引數。在拆分大函式的時候，如果想減少引數的數量，我們可以將引數提公升為類的屬性，而不是方法的引數。如果一來，在拆分大函式為小函式的時候，會擴大類屬性的數量，而這個屬性可能只被極少數的方法所呼叫，從而降低了類的內聚性。出現這種情況時，往往意味著至少有乙個類要從大類中掙扎出來。你應當嘗試將這些變數和方法拆分到兩個或多個類中，讓新的類更為內聚。
沒錯，保持內聚性就會得到許多短小的類。當類喪失了內聚性，就拆分它！所以，將函式拆為許多小函式，往旆也是將類拆分為小類的時機。程式會更加有組織，也會擁有更為透明的結構。
高質量的類，應滿足以下幾點：
1） 單一權責（srp)。 上面講了很多了，如何做到這一點。
2） 開放-閉合原則（ocp）。類應當對擴充套件開放，對修改封閉。（關於這一點，推薦看一下《大話設計模式》，這方面講得非常透徹）
3） 依賴倒置原則（dip）。類應該盡量避免直接對其它類（或例項）進行呼叫，這會讓類了解過多其它類實現的細節，讓類之間產生強耦合。類與類之間的關聯應該通過介面實現，具體來說，如果a類需要呼叫b類的方法，應該將b類通過引數傳給a類，賦值給a類的乙個屬性。b類通過這種方式讓a類呼叫其方法，對於a類來說，它並不依賴b類，只是呼叫自己的屬性的方法。至於屬性從哪兒來，除了賦值那一步，其它任何地方都不用關心。所以如果要做修改，也只用修改自己的屬性，可以很輕易讓自己的屬性指向別的類，易於修改。類和類之間的耦合，僅在於介面處。
高質量的測試 《clean code》讀後感
tdd讓你的 可擴充套件 可維護 可復用，有了測試你就不擔心對 的修改！沒有測試，每次修改都可能帶來缺陷。無論架構多有擴充套件性，無論設計劃分得有多好，沒有了測試，你就很難做改動，因為你擔心改動會不會引入不可預知的缺陷。tdd有三定律 1 在編寫不能通過的單元測試前，不可編寫生產 2 只可編寫剛好無...
讀《高質量C C程式設計指南》
林銳的本書我再一年多以前看過這本書，印象最深的是這本書的附錄 大學十年 如果把寫 想象為搭積木，那麼用一句話描述這本書的內容就是，我們要對 c c 語言這個小積木瞭如指掌，用它們組合成我們想要的圖形，其中不能有任何縫隙。問題產生原因 我們習慣了人與人之間可以含混的語言，原因在於人的糾錯能力太強了。但...
讀《高質量C C 》 預處理
編譯預處理 編譯預處理器能識別的指令，只在預編譯期起作用，不會進入編譯階段。而常用的預編譯處理，主要有檔案包含，巨集定義，條件編譯 error pragma以及預定義符號常量 1 檔案包含 include 例如 include 開發環境提供的庫標頭檔案 include myhead.h 使用者自定義...