簡單設計守則

這個章節名叫做羽化，在閱讀之前我一直很好奇這是什麼意思。當我讀完後我認為這是翻譯後的文雅用法，白話地說該是指昇華。也就是如何讓我們的程式碼好還要更好。

對於促進良好的設計，Kent Beck 提出過「簡單設計四守則」，在幫助提升程式品質上有極好的幫助。根據 Kent 本人的說法，若遵循了以上四個守則，一個設計就可說是簡單的，而這四守則分別是：

• 執行完所有的測試
• 沒有重複的部分
• 表達程式設計師的意圖
• 最小化類別和方法數量

上面的守則，依照重要性來排序。

如果是之前 18 天都讀過的人，應該多少能感受到，其實這些守則跟我們過去所學的，在概念上相當接近。

第一條關於測試，我們在單元測試的篇章提過。測試能幫助我們維持程式的健康程度，有益於程式的彈性與擴張。也因為高耦合的程式碼難以測試，當我們先完成單元測試後再去撰寫產品程式，便能協助我們更多注重依賴反轉 (DIP)、抽象介面等原則或工具，進而達成程式的低耦合及高凝聚。

第二至四條，則關於程式重構。有了測試程式的保護，我們就能放膽去對程式進行重構，善加應用關於良好軟體設計的知識。我們保持函式的簡短與概念的統一、給予具描述力的名稱、幫助類別維持高凝聚、分離關注點......等等。二到四項的守則所要求的，完全包含在我們過去所學。

避免重複

值得一提的是，關於程式的重複，不僅僅是程式碼上的重複，也包含了概念上的重複。
在一個集合 (Collection) 類別中可能有這兩個方法：

int size() {}
boolean isEmpty() {}

當然，我們可以分別實作這兩個方法，亦或者，我們也能在 isEmpty 裡使用 size 的定義，來消除概念上的重複：

boolean isEmpty() {
    return 0 === size();
}

對於消除重複的渴望，是撰寫出整潔程式的一個要素。要記得，當我們替函式做良好地重構時，往往會促使我們的類別擁有更高的凝聚性。

最小化類別和方法數量

然而，對於消除重複程式碼、使程式碼具表達力及單一職責原則等概念，也有可能導致程式設計師們變成教條主義者，為了簡化類別及方法，而在各個方針上做過頭。因此第四守則建議我們，要最小化類別和方法數量，不要過度分割、抽離，導致產生太多的微型類別與方法。

我們目標是類別及函式的簡短，並與此同時讓系統也能簡短。但要謹記，這個守則的重要性排於最末，類別及方法的少量固然重要，但測試、消除重複及表達力，卻是重要中的重要。

小結

已經可以很明顯地感受到，新的概念越來越少出現，而舊理論的各個面向則越來越多被提出討論。看來我可以大膽推測，對於理論的學習已快接近完結，更重要地是接下來的實踐了！