儘管我們將所有心力放在『程式碼敘述和敘述所構成的函式』的表達能力，但除非我們注意程式碼結構的更高層式，否則我們始終無法達到 Cleean Code 的境界。

類別的結構

變數

1. 公用靜態常數
2. 私有靜態變數
3. 私有實體變數
4. 公用變數 (很少會有讓我們使用的好理由)

函式

1. 公用函式
2. 私有工具函式 (緊接放置在呼叫它的公用函式後方)

這遵循了降層法則 (stepdown rule)，有助於『讓閱讀程式』就像在閱讀報紙文章一樣。

封裝

無論如何，會先想辦法保持私有性，放鬆封裝的限制總是最後不得已的手段。

 

類別要夠簡短

在函式裡，我們計算真正的程式行數，來衡量函式的大小。在類別裡，我們利用不同的量測方式，我們計算職責的數量。

• 類別的命名應足以描述其職責
• 使用 25 個字詞內替類別寫出一個簡短的描述

單一職責原則

主張一個類別或一個模組應該有一個，而且只能有一個修改的理由。這個原則同時提供了我們對於職責的定義和類別大小的指導方針。

類別應該只有一個職責 — 唯一的一個修改的理由。

試著確認職責 (修改的理由) 常幫助我們在程式裡，找出或建立較好的抽象概念。
每個小類別『封裝單一的職責』、『只有一個修改的理由』以及『與其它少數幾個類別合作來完成系』。

 

凝聚性

類別應該只有少量的實體變數，類別的每個方法都應該操縱一個或更多個這類型的變數。一般來說，在方法裡操縱越多的變數，代表這個方法更凝聚該類別。
保持函式簡短和保持參數串列夠小的策略，有時會導致某些子方法群使用的實體變數數量增加。這代表著，至少有一個其它類別試著從這個大型類別中離開。

試著分離類別中的變數和方法，使之成為兩個或多個類別，並且讓新的類別擁有更高的凝聚性。

保持凝聚性會得到許多小型的類別

將函式中的變數升等成為類別的實體變數，那我們就能在不傳遞任何參數的情況下，成功地抽取出程式碼。這代表，要將函式拆解為較小的單位應該是容易的事。
將一個大型函式拆解成許多小函式，通常也給我們機會去分割出更多的類別。這會讓我們的程式擁有更好的組織架構和更透明的結構。

重構後程式變長的理由:

• 使用了更長、更具說明性的變數名稱
• 使用了能產生註解效果的函式和類別宣告
• 使用了空白及編排技巧，來維持程式的可讀性

這些改變是藉由，先寫好一套能驗證第一個程式確切行為的測試套件。然後一次一個地進行大量的小型程式變動。

為了變動而構思組織

在一個整潔的系統裡，我們組織類別，以減少改變帶來的風險。
打開一個類別所產生的問題，在於會引來風險。任何對類別的修改，都有潛在的危險，可能會破壞類別其它程式碼的正常功能。所以得進行完全的重新測試。從測試的角度來看，當所有的類別與類別完全切開時，要驗證這個設計的邏輯正確性，是一件簡單到不行的工作。

 

開放-閉合原則 ( Open-Closed Principle, OCP)

類別應該要對擴充具有開放性，但對修改則具有封閉性。對於透過子類別增加新功能是開放的，而當我們在作這樣的修改時，也保持其它類別的封閉且不受影響。

 

隔離修改

• 具體類別 - 包含實現的細節 (程式碼)
• 抽象類別 - 只描述概念、並無實現

我可以利用介面和抽象類別來幫助我們隔離這些細節帶來的風險。利用這樣的方式進行耦合最小化，我們的類別就遵守了『相依性反向原則 (Dependency Inversion Principle, DIP)』的類別設計原則。

相依性反向原則告訴我們，類別應該要相依於抽象概念，而不是相依在具體細節上。

 

參考來源: Clean Code – A Handbook of Agile Software Craftsmanship  by Robert C. Martin