使用部分类来管理代码，很好的解决方案？

Question

书籍通常会说，如果这些类太大而​​无法管理，请重新考虑实现，因为设计需要更正，因为类尚未正确定义。

但是在类确实很大的情况下，例如当一个类被扩展以实现控件的功能时（例如Canvas），并且有很多不同的东西，比如命中测试，绘图，管理绘制的项目在这种情况下使用部分类来分隔更大容器（例如自定义控件）的“不同”事物是否是一个很好的解决方案？

其次，作为更一般和更广泛的解决方案，在转向部分类之前应该考虑什么？

Answer 1

这是一种幻觉。它只是将类分成两个物理文件。你仍然与Single Responsibility Principle，低cohesion等等发生冲突。

部分类主要用于自动代码生成工具。您可以编辑分部类，而不必担心在工具重新生成其他部分时它会被覆盖。

组合是避免大班的几种方法之一。 A类有一个B类实例，并为其部分功能委托给它。在许多情况下，dependency injection可用于解耦这两个类（类A通过类B实现的接口，通常在A的构造函数中）。

Answer 2

是的，如果该类自然大，则使用分部类可以帮助您管理源代码。我之前使用它将单个生产文件的测试拆分为多个源测试文件。同样，当重新实现LINQ to Objects时，我使用了部分类将每个LINQ“运算符”放在它自己的文件中 - 即使它们都对一个名为Enumerable的类做出了贡献。

部分类不是是优秀设计的一个很好的替代方案 - 当你可以使你的实际类更小时，值得这样做。如果你发现你有一个你想要分解的类，部分类可以帮助你将大类重构为两个较小的类 - 你可以将类分成两部分而不改变功能，然后执行真正分裂了一小步。

Answer 3

命中测试似乎不是画布的任务，可以轻松地委托给另一个实现类似

的界面的类

public interface IHitTester
{
    List<Shape> GetHits(List<Shape> allShapes, Point point);
}

它增强了可测试性，允许您尝试不同的命中测试实现（策略模式）并增强代码的可读性。

如果您重新考虑画布类，我确信您可以以相同的方式将其他任务提取到其他类。

Answer 4

我认为在代码生成之外使用这些完全是一种反模式。 它们或多或少相当于再次用于代码生成的区域。我看到一些开发人员出于审美原因使用它们，并称他们的使用重构！当你试图找到一个类的定义并看到几个部分类可供选择时，它并不是很有帮助。我认为开发人员应该使用拆分窗口将同一个文件打开两次，而不是将类的部分内容混入不同的文件中。