Java—在这种情况下，委派是好的解决方案吗？

我的问题是：

我有一个大班（HugeClass），我想把它分成几个小班（LittleClass1，LittleClass2，…）。我听说有一个代表团。这听起来不错，但我认为它在我的情况下不起作用。 事实上，我的小类需要HugeClass的一些属性：

public class  HugeClass
{
    // Attributes
    private Object object1;
    private Object object2;
    private Object object3;
    ...
    private Object objectN;

    // Delegation 1
    private LittleClass1  little1 = new LittleClass1 ();

    // Function delegated in the LittleClass1
    public void  delegated1 ()
    {
        little1.delegated1 ();
    }

}

下面是委派类的示例：

public class  LittleClass1
{
    public LittleClass1 ()
    {

    }

    public void  delegated1 ()
    {
        // Here, I need object1, object3, and more to work !
    }

}

delegated1函数所需的属性数量可能很大。所以我认为使用LittleClass1的构造函数不是很方便

因为LittleClass1只覆盖HugeClass的一个方法，所以我认为LittleClass1不应该扩展HugeClass

你有解决办法吗？使用另一种模式

谢谢

更新

委托函数可能不仅需要实例变量，还需要实例函数：

public class  LittleClass2
{
    public LittleClass2 ()
    {

    }

    public void  delegated2 ()
    {
        // I need object2 and delegated1 to work !
    }

}

---

将HugeClass赋予构造函数可能会解决此问题。但是这是一个好的解决方案吗？

将一个巨大的类拆分为较小的类通常有助于提高代码的可维护性、可测试性和总体质量。较小的数据块应该更容易单独进行推理。您想要的是寻找这个巨大类在语义上不同的特性，并将它们分开，首先通过提取方法，然后通过提取类。你不一定在寻找一个模式，而是在寻找重构技术，比如《重构与重构》一书中的那些技术

现在，如果您的小类似乎共享了巨大类的太多实例变量，那么您可能应该退一步，从一些低挂果实开始，比如不依赖太多变量的代码；或者尝试找到一组在语义上有意义的变量封装在一个新对象中，这将减少这些自由变量的数量并提高设计的质量，因为在设计中找到潜在的概念会使代码更加明确和易懂

---

更新：顺便说一句，继承确实不是个好主意。您希望将关注点解耦，继承只是另一种更微妙的耦合方式。

看起来您只需要

LittleClass1

子类

HugeClass

，其字段

受保护

：

public abstract class HugeClass {
    // Attributes - now protected instead of private
    protected Object object1;
    protected Object object2;
    protected Object object3;
    ...
    protected Object objectN;

    -- Note: No delegation, no reference to LittleClass1 here    

    public abstract void delegated ()

}

public class LittleClass1 extends HugeClass {

    public void delegated () {
        // Here, you have access to object1, object2 etc
    }
}

---

如果能更多地了解

HugeClass

及其职责，那就太好了。你说的“我认为LittleClass1不应该扩展HugeClass”是非常正确的。这不仅是对继承的错误使用，而且也是行不通的。关于解决方案，魔鬼在于细节。因此，请提供这些。HugeClass包含与网站API交互的所有方法。在这个cas中，属性是例如API变量，比如令牌、一些头、一些存根和程序的一些细节。我很确定委派不会以这种方式工作，来自父级的受保护字段将是与当前活动HugeClass实例持有的实例完全不同的实例。很抱歉，您的解决方案似乎误用了继承。考虑重新思考这个问题，然后删除这个答案。1票反对。事实上，我试过这个选项。创建对象HugeClass时，它会实例化委托的对象LittleClass1。LittleClass1扩展了HugeClass，因此您再次实例化了母类，而母类又再次实例化了委托类LittleClass1，等等。我不清楚。但它不起作用。@bill0ute:我也不感到惊讶。你选择了正确的答案。@bill0ute我想你们误解了我的意思。我是说不要授权。只需在需要此类功能的地方创建子类并使用和实例

LittleClass1

。我已经添加了更多的代码（抽象代码）来让这一点非常清楚。顺便说一句，我认为我的答案是好的。@HovercraftFullOfEels我刚刚注意到一个重要的“评论”在被接受的答案上，应该是对这个问题的编辑，它说不同的代表需要相互接触。考虑到这一点，我的答案不起作用（当然），但从技术上讲，这个问题并没有这样说：）这是一个比目前为止其他答案好得多的答案。我本想避免创建包含实例变量的新类，但我认为这是最好的解决方案。谢谢你的邀请！哦，我忘了提一件重要的事情：函数delegated1可能需要函数delegated2（在LittleClass2中）。委托函数不仅需要实例变量，还需要实例函数。解决方案可能是将HugeClass放入每个LittleClass的构造函数的参数中。但它看起来并不可爱。你看到另一种解决方案了吗？@bill0ute：再次尝试重新思考你的重构方法。您希望减少类之间的依赖关系。也许这两种方法的内聚性足以使它们保持在同一个小类中；也许您将一个小类的实例传递给另一个。但是，传递这个庞大的类似乎是错误的，但可能是更好设计的垫脚石。