Question

这是我的问题：

我有一个庞大的类（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赋予构造函数可能会解决此问题。但这是一个很好的解决方案吗？

Answer 1

将较大的类拆分为较小的类通常有助于提高代码的可维护性，可测试性和整体质量。较小的块应该更容易孤立地推理。你想要的是寻找巨大类的语义上不同的特征，并将它们分开，首先是通过提取方法，然后通过提取类。你不一定在寻找一种模式，就像寻找重构技术一样，就像书中重构和Working Effectively with Legacy Code中那样。

现在，如果你的小班级似乎分享了太多类的实例变量，也许你应该退后一步，从一些低悬的果实开始，比如不依赖太多变量的代码;或者尝试找到一组在语义上有意义的变量来封装在一个新对象中，这会减少这些自由变量的数量并提高设计质量，就像找到潜在的概念一样在设计中使代码更加显式和可理解。

UPDATE ：顺便说一下，继承真的不是一个好主意。你想要解决问题，而继承只是另一种更微妙的耦合方式。

Answer 2

您似乎需要LittleClass1来继承HugeClass及其字段protected：

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
    }
}

Java - 在这种情况下授权是一个很好的解决方案吗？

2 个答案: