如何重構上帝式大物件反模式 - Cameron McKenzie

banq發表於2020-03-27
物件模式

僅僅編寫有效的程式碼是不夠的。問題發生時，必須易於維護，增強和除錯該程式碼。物件導向程式設計如此受歡迎的原因之一是因為它滿足了這些要求。
但是，當開發人員選擇捷徑或更多地關注完成工作而不是正確完成工作時，往往會出現反模式。這些常見的反模式之一是上帝式物件。
物件導向程式設計中的主要概念之一是，每個元件都有一個目的，並且該元件僅負責允許其執行相關功能的屬性和欄位。
例如，有時敏捷衝刺太短並且里程碑日期很快就到了，開發人員會自由使用其元件。太多的職責被打包到一個元件中，並且元件之間的職責分離開始變得模糊。
良好的物件導向設計有時會使完成任務的需求倒退，而單一責任模型就會被拋諸腦後。然後，虛無的上帝物件出現了。
簡單來說，God物件是一個違反了單一職責設計模式的Java檔案，因為它：
  • 執行多項任務；
  • 宣告許多不相關的屬性；和
  • 維護一組方法，這些方法彼此之間沒有邏輯關係，除了執行對應用程式功能至關重要的操作外。

您如何在物件導向的系統中修復God物件？重構它。請遵循以下五個步驟來重構上帝物件和整理程式碼。

1.建立一個全面的單元測試套件
建立一套單元測試，以正確驗證God物件的功能。這樣，您可以自信地重構上帝的物件。如果您碰巧破壞了某些內容，則單元測試將使您警惕任意程式碼。

2.識別客戶
在重構God類之前，請確定從何處引用God物件的方法。是在整個應用程式中平等使用God物件，還是從一組特定的子元件中呼叫方法？
找出最依賴上帝物件的元件有多個目的：
  • 優先考慮重構應用程式的哪些部分。在進行影響關鍵系統的程式碼提交之前，請考慮重構不經常使用的區域。
  • 如果給定的子元件集通常呼叫一組通用方法，則根據子元件用法將God物件分解為較小的物件集，作為可能的分解策略。
  • 給定的一組客戶端呼叫的一組通用方法代表定義一個RESTful或基於微服務的介面的機會，該介面既鬆散耦合又引入了使應用程式成為雲原生的機會。


3.將靜態方法分解為實用程式類
例項是物件導向程式設計的基礎。靜態方法是未在任何例項變數中傳遞的方法。這樣，如果將靜態方法和靜態變數移到單個實用程式類中，則可以檢視其餘的屬性和變數，並開始建立較小的單一職責物件。
但是，實用程式類並不是特別物件導向的。處理完靜態方法後，請考慮將系統中的實用程式類分解為更物件導向的東西。但是，設計中的一些實用程式類比上帝物件要少很多問題。

4.分組通用方法和屬性
此時，上帝物件中保留有例項變數和例項方法。將它們重構為物件。使用繼承，聚合和關聯等通用的物件導向原則來表達您建立的物件之間的關係。同時，請遵守Demeter定律，以確保您仍然擁有鬆散耦合的系統。

5.刪除或棄用上帝的物件
如果成功重構了God物件，請從設計中刪除該元件。該系統應以與以前相同的方式執行。
完成此步驟後，請隨時引用弗里德里希·尼采的話：“上帝已經死了”
刪除God物件後，如果在客戶端和子元件程式碼中建立了編譯問題，請不要擔心。您可以將God物件更改為介面，或者至少將其轉換為沒有例項變數的Facade物件。然後，God物件中的方法將工作簡單地委派給各種實用程式類，並在重構God物件時建立較小的物件。
如果您確實採用立面方法，請確保將每個方法都標記為已棄用，以便將來的開發知道呼叫分解後的物件，而不是上帝物件本身。

回顧重構上帝物件的五個步驟
請遵循以下五個步驟來反轉上帝物件反模式：
  1. 構建一個全面的單元測試套件。
  2. 確定最依賴上帝的物件元件。
  3. 將靜態方法移到實用程式類中。
  4. 對常用方法和屬性進行分組，但要保持鬆散耦合的系統。
  5. 從系統設計中刪除God物件。

相關文章