这是我的问题：
我有一个巨大的类（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 !
}
}
委托1函数所需的属性数量可能很大。因此，我认为使用LittleClass1的构造函数不是很方便。
而且由于LittleClass1仅覆盖HugeClass的一种方法，所以我认为LittleClass1不应该扩展HugeClass。
您有解决方案的想法吗？使用其他模式？
谢谢 ！
更新资料
委托的函数可能不仅需要实例变量，还需要实例函数：
public class LittleClass2
{
public LittleClass2 ()
{
}
public void delegated2 ()
{
// I need object2 and delegated1 to work !
}
}
将HugeClass提供给构造函数可能会解决此问题。但这是一个好的解决方案吗？
最佳答案
将庞大的类分成较小的类通常可以提高代码的可维护性，可测试性和整体质量。较小的块应该更容易被隔离。您想要的是查找巨大类的语义上不同的功能，然后首先通过提取方法，然后通过提取类将它们分开。您不一定要寻找一种模式，就像寻找重构技术一样，就像书籍Refactoring和Working Effectively with Legacy Code中的那些一样。
现在，如果您的小类似乎共享了巨大类的太多实例变量，那么也许您应该退后一步，从一些低沉的果实开始，例如不依赖太多变量的代码；或尝试找到在语义上有意义的变量组，以将其封装在新对象中，这将减少这些自由变量的数量并提高设计质量，因为在设计中查找潜在概念会使代码更加明确和可理解的。
更新：顺便说一句，继承确实不是一个好主意。您想使关注点分离，而继承只是耦合的另一种更微妙的方式。