上帝物件

上帝物件（英語：God object）是物件導向程式設計中了解過多或者負責過多的物件，為一種反面模式。上帝物件通常出現在設計不良的系統中。

特徵

以下為一個上帝物件的Java範例：

public class GodObject {
    private int data;

    public void processData() {
        // 非常複雜的處理邏輯
        // 涉及多個不同的功能和方法邏輯
        // 違反單一職責原則
    }

    public void saveData() {
        // 將數據儲存到資料庫
        // 涉及與資料庫的連接和互動
        // 違反低耦合性原則
    }

    public void displayData() {
        // 顯示數據到用戶介面
        // 涉及與介面層的互動
        // 違反低耦合性原則
    }
    
    // 其他許多方法和屬性...
}

範例中所示的GodObject類別有太多的功能和責任，不遵從單一功能原則，包攬所有處理、儲存和顯示數據的操作。processData方法中的處理邏輯非常複雜，應該將該邏輯根據功能分解成更小的方法或抽象成獨立的類別。saveData和displayData方法與資料庫和用戶介面直接耦合，降低可測試性和可延伸性。

上帝物件通常包含過多的方法和屬性，導致類別過於龐大。上帝物件違背單一功能原則和其他SOLID原則，功能過於集中在一個類別中。上帝物件負責處理系統中的所有複雜邏輯和功能，導致物件變得難以理解和維護。上帝物件通常不依循常見設計模式，例如分層結構、策略模式、觀察者模式等，而是採取了導致程式設計問題的反面模式。上帝物件通常將無關的功能集中在一個類別中，導致功能緊密耦合，難以單獨測試、修改。上帝物件不遵守分治演算法，即將一個複雜的問題分成更小、可管理的部分，反而把所有功能集中在一個類別中，增加問題複雜度和難度。

危害

上帝物件繼承時，所有不需要的成員都會繼承到其他類別中，因此不適合重複使用。上帝物件非常大，會佔用大量記憶體空間。上帝物件必須處理大量的功能和行為，會佔用許多不需要的資源，即使執行簡單操作時也是如此。上帝物件還會導致嚴密的耦合，難以維護和擴展，而且上帝物件涉及了太多功能和行為，很難涵蓋測試。

解決方式

代碼重構能解決上帝物件的問題。只要將相關功能拆分成獨立組合，就可以獨立修改，並且能夠適應系統變化。

首先，建立一個全面的單元測試套件，以驗證上帝物件的功能，即可放心重構，並在需要時快速反饋。確定哪些部分的程式碼會使用上帝物件的方法，找出最常使用上帝物件的組件，重點處理這些組件的重構。接着，將靜態方法和靜態變數轉移到一個實用程式類別中，即可減少上帝物件的大小，同時確保功能的可重用性。根據相關性和功能，將上帝物件的方法和屬性重構為更小、單一責任的物件。使用繼承、聚合和關聯等物件導向原則來表達這些物件之間的關聯。最後，刪除完成重構的上帝物件，或者標記為過時，並且遵守得墨忒耳定律，系統就會像正常運作。

重構上帝物件可能會在客戶端和子組件的程式碼中引起編譯問題，這時可以將上帝物件轉換為介面或者外觀物件。外觀物件不包含實例變數，而只將工作委派給進行重構後的較小物件和實用程式類別。

參見

• 餛飩式代碼：和上帝物件恰好相反的反模式。

延伸閱讀

• Anti-Patterns and Worst Practices – Monster Objects （頁面存檔備份，存於互聯網檔案館）