# 章節八 重新組織數據 本章之中，我將討論數個「能讓你更輕松運用數據」的重構手法。很多人或許會認為Self Encapsulate Field 有點多余，但是關于「對象應該直接訪問其中的數據，抑或應該通過訪問函數（accessor）來訪問」這一問題，爭論的聲音從來不曾停止。有時候你確實需要訪問函數，此時你就可以通過Self Encapsulate Field 得到它們。通常我會選擇「直接訪問」方式，因為我發現，只要我想做，任何時候進行這項重構都是很簡單的。 面向對象語言有一個很有用的特征：除了允許使用傳統語言提供的簡單數據型別，它們還允許你定義新型別。不過人們往往需要一段時間才能習慣這種編程方式。一開始你常會使用一個簡單數值來表示某個概念；隨著對系統的深入了解，你可能會明白，以對象表示這個概念，可能更合適。 Replace Data Value with Object 讓你可以將「啞」數據（dumb data）變成會說話的對象（articulate objects）。如果你發現程序中有太多地方需要這一類對象，你也可以使用Change Value to Reference 將它們變成reference object。 如果你看到一個array的行為方式很像一個數據結構，你可以使用 Replace Array with Object 把array變成對象，從而使這個數據結構更清晰地顯露出來。但這只是第一步，當你使用Move Method 為這個新對象加入相應行為時，真正的好處才得以體現。 魔法數（magic numbers），也就是帶有特殊含義的數字，從來都是個問題。我還清楚記得，一開始學習編程的時候，老師就告訴我不要使用魔法數。但它們還是不時出現。因此，只要弄清楚魔法數的用途，我就運用 Replace Magic Number with Symbolic Constant 將它們除掉，以絕后患。 對象之間的關聯（links）可以單向，也可以雙向。單向關聯比較簡單，但有時為了支持一項新功能，你需要以Change Unidirectional Association to Bidirectional 將它變成雙向關聯。Change Bidirectional Association to Unidirectional 則恰恰相反：如果你發現不再需要雙向關聯，可以使用這項重構將它變成單向關聯。 我常常遇到這樣的情況：GUI classes竟然去處理不該它們處理的業務邏輯（business logic）。為了把這些處理業務邏輯的行為移到合適的domain class去，你需要在domain class中保存這些邏輯的相關數據，并運用 Duplicate Observed Data 提供對GUI的支持。一般來說，我不喜歡重復的數據，但這是一個例外，因為這里的重復數據通常是不可避免的。 面向對象編程（OOP）的關鍵原則之一就是封裝。如果一個class暴露了任何public數據，你就應該使用Encapsulate Field 將它高雅而正派地包裝起來。如果被暴露的數據是個群集（collection），你就應該使用Encapsulate Collection 因為群集有其特殊協議。如果一整筆記錄（record）都被裸露在外，你就應該使用 Replace Record with Data Class。 需要特別對待的一種數據是type code〔型別碼）：這是一種特殊數值，用來指出 「與實體所屬之型別相關的某些東西」。Type code通常以枚舉（enumeration）形式出現，并且通常以static final整數實現之。如果這些type code用來表現某種信息，并且不會改變所屬class的行為，你可以運用 Replace Type Code with Class 將它們替換掉，這項重構會為你提供更好的型別檢查，以及一個更好的平臺，使你可以在未來更方便地將相關行為添加進去。另一方面，如果class的行為受到type code的影響，你就應該盡可能使用Replace Type Code with Subclasses。如果做不到，就只好使用更復雜（同時也更靈活）的 Replace Type Code with State/Strategy。