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

bil*_*ute 2 java architecture overriding design-patterns delegation

这是我的问题:

我有一个庞大的类(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 ();
    }

}
Run Code Online (Sandbox Code Playgroud)

这是一个Delegation类的示例:

public class  LittleClass1
{
    public LittleClass1 ()
    {

    }

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

}
Run Code Online (Sandbox Code Playgroud)

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

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

你有解决方案的想法吗?使用其他模式?

谢谢 !

更新

委托函数可能不仅需要实例变量,还需要实例函数:

public class  LittleClass2
{
    public LittleClass2 ()
    {

    }

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

}
Run Code Online (Sandbox Code Playgroud)

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

Jor*_*dão 7

将一个庞大的类分解成更小的类通常可以提高代码的可维护性,可测试性和整体质量.较小的块应该更容易孤立地推理.你想要的是寻找巨大类的语义上不同的特征,并将它们分开,首先是通过提取方法,然后通过提取类.你不一定在寻找一种模式,就像寻找重构技术一样,就像重构有效使用遗留代码这本书中的重构技术一样.

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

更新:顺便说一句,继承真的不是一个好主意.您想要解耦问题,而继承只是另一种更微妙的耦合方式.