代碼整潔之道-第10章-類-讀書筆記

第 10 章 類

　　要將注意力放到代碼組織的更高層面，才能獲得整潔的代碼。

10.1 類的組織

　　遵循標準的 Java 約定，類應該從一組變量列表開始。若是有公共靜態變量，應該先出現。而後是私有靜態變量，以及私有實體變量。不多會有公共變量。
　　公共函數應跟在變量列表以後。咱們喜歡把由某個公共函數調用的私有工具函數緊隨在該公有函數後面。這符合了自頂向下原則，讓程序讀起來就像一篇報紙文章。
　　封裝
　　若同一程序包內的某個測試須要調用一個函數或變量，咱們就會將該函數或變量置爲受保護或在整程序包內可訪問。然而，咱們首先會想辦法使之保有隱私。放鬆封裝老是下策。

10.2 類應該短小

　　關於類的第一條規則是類應該短小。第二條規則是還要更短小。
　　對於函數，咱們經過計算代碼行數衡量大小。對於類，咱們採用不一樣的衡量方法，計算權責（responsibility）。
　　類的名稱應當描述其權責。實際上，命名正是幫助判斷類的長度的第一個手段。若是沒法爲某個類命以精確的名稱，這個類大概就太長了。類名越含混，該類越偶可能擁有過多權責。
　　咱們也應該可以用大概 25 個單詞簡要描述一個類，且不用「若（if）」、「與（and）」、「或（or）」或者「但（but）」等詞彙。若是用若、與、或、但就說明類有太多權責。

10.2.1 單一權責原則

　　單一權責原則（SRP）認爲，類或模塊應有且只有一條加以修改的理由。該原則既給出了權責的定義，又是關於類的長度的指導方針。類只應有一個權責—只有一條修改的理由。
　　鑑別權責（修改的理由）經常幫助咱們在代碼中認識到並建立出更好的抽象。
　　系統應該由許多短小的類而不是少許巨大的類組成。每一個小類封裝一個權責，只有一個修改的緣由，並與少數其餘類一塊兒協同達成指望的系統行爲。

10.2.2 內聚

　　類應該只有少許實體變量。類中的每一個方法都應該操做一個或多個這種變量。一般而言，方法操做的變量越多，就越黏聚到類上。若是一個類中的每一個變量都被每一個方法所使用，則該類具備最大的內聚性。
　　通常來講，建立這種極大化內聚類是既不可取也不可能的；另外一方面，咱們但願內聚性保持在較高位置。內聚性高，意味着類中的方法和變量互相依賴、互相結合成一個邏輯總體。
　　保持函數和參數列表短小的策略，有時會致使爲一組子集方法所用的實體變量數量增長。出現這種狀況時，每每意味着至少有一個類要從大類中掙扎出來。你應當嘗試將這些變量和方法分拆到兩個或多個類中，讓新的類更爲內聚。

10.2.3 保持內聚性就會獲得許多短小的類

　　當類喪失了內聚性，就拆分它！
　　將大函數拆分紅許多小函數，每每也是將類拆分爲多個小類的時機。程序會更加有組織，也會擁有更爲透明的結構。
　　重構後的程序更長的緣由：其一，重構後的程序採用了更長、更有描述性的變量名。其二，重構後的程序將函數和類聲明看成是給代碼添加註釋的一種手段。其三，咱們採用了空格和格式技巧讓程序更可讀。

10.3 爲了修改而組織

　　出現了只與類的一小部分有關的私有方法行爲，意味着存在改進空間。
　　開放-閉合原則（OCP）：類應當對擴展開放，對修改封閉。
　　隔離修改
　　部件之間的解耦表明着系統中的元素互相隔離得很好。隔離也讓對系統每一個元素的理解變的更加容易。
　　經過下降鏈接度，咱們的類就遵循了另外一條類設計原則，依賴倒置原則（Dependency Inversion Principle,DIP）。本質而言，DIP 認爲類應當依賴於抽象而不是依賴於具體細節。

10.4 文獻