第 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 認爲類應當依賴於抽象而不是依賴於具體細節。