上帝对象

上帝物件（英语：God object）是物件导向程式设计中了解过多或者负责过多的对象，为一种反面模式。^[1][2]上帝物件通常出现在设计不良的系统中。^[3]

特征

以下为一个上帝物件的Java范例：

public class GodObject {
    private int data;

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

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

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

范例中所示的GodObject类别有太多的功能和责任，不遵从单一功能原则，包揽所有处理、储存和显示数据的操作。processData方法中的处理逻辑非常复杂，应该将该逻辑根据功能分解成更小的方法或抽象成独立的类别。saveData和displayData方法与资料库和使用者介面直接耦合，降低可测试性和可扩展性。

上帝物件通常包含过多的方法和属性，导致类别过于庞大。^[4]上帝物件违背单一功能原则和其他SOLID原则，功能过于集中在一个类别中。上帝物件负责处理系统中的所有复杂逻辑和功能，导致物件变得难以理解和维护。上帝物件通常不依循常见设计模式，例如分层结构、策略模式、观察者模式等，而是采取了导致程式设计问题的反面模式。上帝物件通常将无关的功能集中在一个类别中，导致功能紧密耦合，难以单独测试、修改。上帝物件不遵守分治算法，即将一个复杂的问题分成更小、可管理的部分，反而把所有功能集中在一个类别中，增加问题复杂度和难度。^[5]

危害

上帝物件继承时，所有不需要的成员都会继承到其他类别中，因此不适合重复使用。上帝物件非常大，会占用大量记忆体空间。上帝物件必须处理大量的功能和行为，会占用许多不需要的资源，即使执行简单操作时也是如此。上帝物件还会导致严密的耦合，难以维护和扩展，而且上帝物件涉及了太多功能和行为，很难涵盖测试。^[5]

解决方式

代码重构能解决上帝物件的问题。只要将相关功能拆分成独立组合，就可以独立修改，并且能够适应系统变化。^[5]

首先，建立一个全面的单元测试套件，以验证上帝物件的功能，即可放心重构，并在需要时快速回馈。确定哪些部分的程式码会使用上帝物件的方法，找出最常使用上帝物件的组件，重点处理这些组件的重构。接著，将静态方法和静态变数转移到一个实用程式类别中，即可减少上帝物件的大小，同时确保功能的可重用性。根据相关性和功能，将上帝物件的方法和属性重构为更小、单一责任的物件。使用继承、聚合和关联等物件导向原则来表达这些物件之间的关联。最后，删除完成重构的上帝物件，或者标记为过时，并且遵守得墨忒耳定律，系统就会像正常运作。^[6][7][8]

重构上帝物件可能会在客户端和子组件的程式码中引起编译问题，这时可以将上帝物件转换为介面或者外观物件。外观物件不包含实例变数，而只将工作委派给进行重构后的较小物件和实用程式类别。^[7]

参见

• 馄饨式代码：和上帝物件恰好相反的反模式。