Visual Studio每个方法部分类的缺点

我可以看到的好处是文件中要查看的代码更少，所以不是在大文件中上下滚动，你只会看到处理你正在处理的方法的代码。此外，如果您正在使用源代码控制，合并将更容易，因为您只需要处理每个方法中的代码。而且由于方法是由物理文件绑定的，您可以通过查看文件的更改历史来轻松地查看方法的更改历史。

在我看来，所有这些好处，只有在类太大的情况下才是"好处"。如果你的类遵循单一职责原则，那么文件就不应该"太大"而无法管理。

而且，大多数ide(比如Visual Studio)已经提供了大量快速导航文件的功能(比如直接跳转到成员的下拉菜单)。

我能看到的缺点是有很多小文件，但我不认为这将是那么糟糕。这种思路还有其他缺点吗?

您将类型拆分到多个文件中，这使得它的可维护性大大降低，并且更难以遵循，因为类型使用的数据不再接近使用它的方法。

您还为重构增加了额外的维护成本，例如，方法重命名现在需要额外的工作(文件重命名)，这将打破该文件中该方法的"历史记录"。

总的来说，我觉得这是一个不好的做法。如果您已经生成了代码，并且希望能够将其他逻辑添加到生成的代码文件中，那么部分类是非常好的，但除此之外，我个人倾向于避免使用部分类。

这对我来说是一种代码气味:一个足够大的类，通过划分成多个部分来理解某些东西，这表明它有太多的责任。这可能是一个考虑不周的抽象，应该划分为多个类。

例如，如果我有一个名为Customer的类，它有一些属性和两个方法:GetOrders和GetAddress。我将创建一个名为Customer.cs的文件，并将属性和两个方法的所有代码放在该文件中，而不是创建一个名为Customer.cs的文件，并仅将属性放在该文件中。我认为这门课是偏颇的。然后，我将在一个名为Customer_GetOrders.cs和Customer_GetAddress.cs的新文件中创建每个方法，每个方法都包含一个标记为部分的Customer类，并且仅包含该方法的代码。在Visual Studio中，我会在Customer.cs文件下嵌套Customer_GetOrders.cs和Customer_GetAddress.cs文件。

从建模角度来看，GetAddress()和GetOrders()不应该是方法，至少在Customer对象上不应该是方法。一个Customer可能有1个或多个Address 属性和一个类似集合的属性 Orders，它表示客户的订单历史。

我认为你的抽象缺少一些类。也许您需要一个OrderFactory，给定Customer(可能还有其他条件)，它知道如何查找一个或多个客户的订单。

实际上visual studio存在一个大问题。文件越多，编译甚至加载解决方案所需的时间就越长。有时候可以尝试使用大量文本文件，想象一下每个类有7或8个额外的文件，标准解决方案的大小很快就会爆炸。

从。net编译器的角度来看，这没有什么错。

唯一的其他问题是可维护性，即代码导航知道什么去哪里。