使用分部类来管理代码，这是一个很好的解决方案

本文关键字：一个 解决方案 很好 代码 管理 | 更新日期: 2023-09-27 18:21:37

书籍通常说，如果类变得太大而无法管理，请重新考虑实现，因为由于类没有正确定义，设计很可能需要更正。

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

其次，作为一个更通用、更广泛的解决方案，在转到Partial类之前应该考虑什么？

使用分部类来管理代码，这是一个很好的解决方案

这是一种幻觉。它只是将类分成两个物理文件。你仍然与单一责任原则、低凝聚力等相冲突。

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

组合是避免大型类的几种方法之一。类A有一个类B的实例，并将其部分功能委托给它。在许多情况下，依赖注入可以用于解耦两个类（类A被传递一个类B实现的接口，通常在A的构造函数中）。

是的，如果类自然地很大，那么使用分部类可以帮助您管理源代码。我以前使用过这个方法，将单个生产文件的测试拆分为多个源测试文件。同样，当重新实现LINQ到对象时，我使用分部类将每个LINQ"运算符"放在自己的文件中——尽管它们都贡献给了一个名为Enumerable的类。

然而，分部类并不是好设计的好选择-当你可以缩小你的实际类时，这样做是值得的。如果你发现你有一个想要分解的小类，分部类可以帮助你将大类重构为两个较小的类-你可以在不改变功能的情况下将类划分为两个部分，然后以较小的步骤执行实际拆分。

Hit测试似乎不是画布的任务，可以很容易地委托给另一个实现之类接口的类

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

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

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

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

相关文章：