程式碼整潔之道 讀書筆記 - 第10章 類
類應該短小
1、單一權責原則（SRP）
系統應該由許多短小的類而不是少量巨大的類組成。
每個小類封裝一個權責，只有一個修改的原因，並與少數其他類一起協同達成期望的系統行為。
2、內聚
類應該只有少量實體變數。類中的每個方法都應該操作一個或多個這種變數。
3、保持內聚性就會得到許多短小的類
為了修改而組織
隔離修改，藉助介面和抽象類來隔離實現細節（程式碼）帶來的影響。
相關推薦
程式碼整潔之道 讀書筆記 - 第10章 類
類應該短小 1、單一權責原則（SRP） 系統應該由許多短小的類而不是少量巨大的類組成。 每個小類封裝一個權責，只有一個修改的原因，並與少數其他類一起協同達成期望的系統行為。 2、內聚 類應該只有少
程式碼整潔之道 讀書筆記 - 第3章 函式
短小 函式的第一規則是要短小。第二條規則是還要更短小。 函式20行封頂最佳。 if語句、else語句、while語句等，其中的程式碼塊應該只有一行，而且，塊內呼叫的函式擁有較具說明性的名稱，還能起到文件的作用。 只做一件事 函式應該做一件事。做好這件事。只做這一件事。 每個函式一個抽象層級 自頂
程式碼整潔之道 讀書筆記 - 第5章 格式
垂直格式 1、推薦單檔案200行程式碼左右，最長不超過500行。 2、每一組思路完整的程式碼，中間用空白行區隔。 3、緊密相關的程式碼應該互相靠近。 4、本地變數和實體變數應該在類的頂部宣告。 5、概念相關的程式碼應該放在一起，相關性越強，距離越短。 6、自上向下展示函式呼叫依賴順序。被呼叫的函式
程式碼整潔之道 讀書筆記 - 第6章 物件和資料結構
資料結構、物件的反對稱性 物件（物件式程式碼）曝露行為，隱藏資料。便於新增新物件型別而無需修改既有行為，同時也難以在既有物件中新增新行為。 資料結構（過程式程式碼）曝露資料，沒有明顯的行為。便於向既有資料結構新增新行為，同時也難以向既有函式新增新資料結構。 在任何系統中，我們有時會希望能夠靈活地新增新資
程式碼整潔之道 讀書筆記 - 第8章 邊界
1、使用第三方程式碼，如果使用邊界介面，就把它保留在類或近親類中。避免從公共API中返回邊界介面，或將邊界介面作為引數傳遞給公共API。 2、瀏覽和學習邊界，不要在生產程式碼中試驗新東西，而是編寫測試來遍覽和理解第三方程式碼。Jim Newkirk把這個叫做學習性測試。 3、學習性測試的好處不只是免費，能
程式碼整潔之道讀書筆記--函式
好函式的需要滿足： 1. 短小: 經過漫長的試錯，經驗告訴我，函式就該小。 一個強制性的原則是，程式碼長度最好20行封頂。 2.程式碼塊和縮排: if、else、while語句等，其中的語句只有一個，就是一個函式呼叫語句；
程式碼整潔之道讀書筆記--物件和資料結構
1.過程式程式碼VS面向物件程式碼 過程式程式碼便於在不改動既有資料結構的前提下新增新函式。面向物件程式碼便於在不改動既有函式的前提下新增新類。 反過來說： 過程式程式碼難以新增新資料結構
程式碼整潔之道讀書筆記--註釋
註釋的恰當用法是彌補我們在用程式碼無法表達意圖是遭遇的失敗。注意，我用來“失敗“一次。我是說真的。我們總無法找到不用註釋就能表達自我的方法，所以總要有註釋，這並不值得慶賀。 程式設計師應當負責將註釋保持在可維護、有關聯、精確的高度。我同意這一說法
程式碼整潔之道讀書筆記--類
1.類的組織 遵循標準的Java約定，類應該從一組變數列表開始。如果有公共靜態常量，應該先出現。然後是私有靜態變數，以及私有實體變數。很少會有公共變數。 公共函式應跟在變數列表之後。把由某個公共函式呼叫的私有工具函式緊隨在該公共函式後面，這符合了自頂向下
程式碼整潔之道讀書筆記——第二章：有意義的命名
第二章 有意義的命名 2.1 介紹 在軟體開發中，我們各種命名，不斷的命名，有這麼多的命名，一定要做好它！ 2.2 名副其實 選個好名字要花很多時間，而且對於我們中國的程式設計師來說，選一個好的英文名字更要精挑細選，但是省下來的時間遠比花掉的多，一個名稱基本就答
程式碼整潔之道讀書筆記——第一章：整潔程式碼
軟體質量，不僅僅依賴於專案架構和專案管理，同樣重要的是程式碼質量！！！ 序 神在細節之中，其實幹什麼事都一樣，從小到大，一直明白一個道理：細節決定成敗！ 軟體架構在開發中佔據重要地位。其次，巨集達建築的最細小的部分，比如關不緊的門、有點沒鋪平的地板，甚至是凌亂的桌
我讀-程式碼整潔之道---讀書筆記整理
第一章 整潔程式碼 "我可以列出我留意到的整潔程式碼的所有特點,但其中有一條是根本性的,整潔的程式碼總是看起來像是某位特別在意他的人寫的.幾乎沒有改進的餘地,程式碼作者設麼都想到了,如果你企圖改進它,總會回到原點,讚歎某人留給你的程式碼" ---Michael Feat
程式碼整潔之道閱讀筆記_第3次
第13~17章 13、併發程式設計：單一權責原則、儘可能減小同步區域、限制資料作用域、有些java類不是執行緒安全，測試執行緒程式碼。由於對併發程式設計應用不多，只是簡單的理解為以上幾點。 14、逐步改進：漸進不改進之名大動其結構保持可執行、測試驅動開發 15、JUni
程式碼整潔之道-第2章-有意義的命名-讀書筆記
第 2 章 有意義的命名 15-28 2.1 介紹 文章列出取個好名字的幾條簡單規則。 2.2 名副其實 程式碼的模糊度：即上下文在程式碼中未被明確體現的程度。 2.3 避免誤導 程式設計師必須避免留下掩藏程式碼本意的錯誤線索。應當避免使用與本意相悖的詞。 提防使用不同之處較小的名
斷舍離 ——《程式碼整潔之道》讀書筆記
注：只看了書的前十章 第一章 為什麼要整潔程式碼 1、程式碼永不消失 程式碼就是銜接人腦理解需求的含糊性和機器指令的精確性的橋樑。哪怕未來會有對現在高階程式語言的再一次抽象——但這個抽象規範自身仍舊是程式碼。 所以既然程式碼會一直存在下去，且自己都幹了程式設計師這一行了，就好好的對待它吧。 2、讀遠比寫
《程式碼整潔之道》讀書筆記
最初我喜歡這本書可能是因為非技術方面的原因，這本書中有很多我喜歡的插圖。這本書的第一章的第一句話是這樣說的：讀這本書通常有兩個原因：1. 你是一名程式設計師。2. 你想成為更好的程式設計師。我們需要更好的程式設計師。 這本書的每一章都可以總結出一句話，其實每章開始的
程式碼整潔之道（Clean Code）- 讀書筆記
一、關於Bob大叔的Clean Code 《程式碼整潔之道》主要講述了一系列行之有效的整潔程式碼操作實踐。軟體質量，不但依賴於架構及專案管理，而且與程式碼質量緊密相關。這一點，無論是敏捷開發流派還是傳統開發流派，都不得不承認。這本書的閱讀物件為一切有志於改善程式碼質量的程式設計師，書中介紹的規則均來自作
Atitit soa之道 艾提拉著作 SOA概念、技術與設計讀書筆記 第3章 理解面向服務 10 第4章 理解面向服務架構 39 第5章 理解服務與微服務的層次 74 第6章 Web服務及微服務的
Atitit soa之道 艾提拉著作 SOA概念、技術與設計讀書筆記 第3章 理解面向服務 10 第4章 理解面向服務架構 39 第5章 理解服務與微服務的層次 74 第6章 Web服務及微服務的分析與建模 94 第7章 REST服務及微服務的
程式碼整潔之道 clean code 讀書筆記
《程式碼整潔之道》 給出關於提高程式碼質量和可讀性的建議。 一些建議對初學者非常有用。下面是我的幾條筆記。 關於變數名、函式或類的名稱 第2章 有意義的命名 2.2 名副其實 變數、函式或類的名稱應該告訴你 它是什麼、能做什麼、該怎麼用。 Int d; //消
《程式碼整潔之道》學習筆記一（前三章）
我們都曾經瞟一眼自己親手造成的混亂，決定棄之於不顧，走向新的一天。 我們都曾經說過有朝一日要回頭清理。 當然，那是我們都沒聽過勒布朗法則：稍後等於永不（Later equals never）。 隨著混亂的增加，團隊的生產力不斷下降，趨向於零。 假如你是位醫生，病人請求你