书籍通常会说，如果类太大而无法管理，请重新考虑实现，因为很有可能设计需要更正，因为类没有正确定义。
但是在类确实很大的情况下，例如当一个类被扩展以实现控件的功能时（例如 Canvas），并且有许多不同的事情，如命中测试、绘图、管理绘制的项目等等。在这种情况下使用分部类来分隔更大容器（例如自定义控件）的“不同”事物是否是一个很好的解决方案？
其次，作为更通用和更广泛的解决方案，在迁移到 Partial 类之前应该考虑什么？
【问题讨论】：
标签： c# coding-style refactoring partial-classes code-cleanup
我认为在代码生成之外使用这些完全是反模式。 它们或多或少等同于再次用于代码生成的区域。我看到一些开发人员出于审美原因使用它们并称它们为使用重构！当你试图找到一个类的定义并看到几个部分类可供选择时，它并不是很有帮助。我认为开发人员应该使用拆分窗口来两次打开同一个文件，而不是将类的部分内容混入不同的文件中。
【讨论】：
这是一种错觉。它只是将类分成两个物理文件。你仍然与Single Responsibility Principle、低cohesion等发生冲突。
部分类主要用于自动代码生成工具。您可以编辑部分类，而不必担心当工具重新生成其他部分时它会被覆盖。
组合是避免大类的几种方法之一。 A 类具有 B 类的一个实例，并委托给它以实现其部分功能。在很多情况下，dependency injection 可以用来解耦两个类（A 类被传递一个 B 类实现的接口，通常在 A 的构造函数中）。
【讨论】：
是的，如果类自然很大，使用分部类可以帮助您管理源代码。我之前使用它来将单个 production 文件的测试拆分为多个源测试文件。同样，在重新实现 LINQ to Objects 时，我使用部分类将每个 LINQ“操作符”放在自己的文件中——即使它们都贡献了一个名为 Enumerable 的类。
部分类并不是好的设计的一个很好的替代品——当你可以让你的实际类更小时，这样做是值得的。如果你发现你有一个想要分解的类，部分类可以帮助你将大类重构为两个更小的类 - 你可以将类分成两个部分而不改变功能，然后执行真正的分裂在一个更小的步骤。
【讨论】：
命中测试似乎不是画布的任务，可以很容易地委托给另一个实现类似接口的类
public interface IHitTester
{
List<Shape> GetHits(List<Shape> allShapes, Point point);
}
它增强了可测试性，允许您尝试不同的命中测试实现（策略模式）并增强代码的可读性。
如果您重新考虑您的画布类，我相信您可以以相同的方式将其他任务提取到其他类。
【讨论】：