在处理大型类时，或在团队中工作时，尽可能保持所有内容的干净，您可以在不重写的情况下编辑(或始终提交更改)

部分类最近帮助了源代码控制，多个开发人员在一个文件中添加新方法，并将其添加到文件的同一部分(由Resharper自动化)。

这些推入git会导致合并冲突。我发现没有办法告诉合并工具把新方法作为一个完整的代码块。

在这方面，部分类允许开发人员坚持他们文件的一个版本，并且我们可以稍后手工将它们合并回去。

的例子,

cs—保存字段、构造函数等 MainClass1.cs—开发人员实现时的新代码 cs -是另一个用于新代码的开发人员类。

在处理大型类时，或在团队中工作时，尽可能保持所有内容的干净，您可以在不重写的情况下编辑(或始终提交更改)

部分类的最大用途是使代码生成器/设计人员的工作更轻松。部分类允许生成器简单地发出它们需要发出的代码，而不需要处理用户对文件的编辑。用户同样可以通过创建第二个分部类来自由地用新成员注释类。这为关注点分离提供了一个非常清晰的框架。

更好的方法是看看设计器在部分类之前是如何工作的。WinForms设计器会吐出区域内的所有代码，并给出不修改代码的强烈注释。它必须插入各种启发式方法来找到生成的代码，以便稍后进行处理。现在它可以简单地打开designer.cs文件，并有高度的信心它只包含与设计器相关的代码。

服务引用是另一个例子，其中部分类用于将生成的代码与用户创建的代码分开。

您可以在更新服务引用时“扩展”服务类，而不必覆盖它们。

除了其他答案之外……

我发现它们可以作为重构神类的垫脚石。如果一个类有多个职责(特别是如果它是一个非常大的代码文件)，那么我发现为每个职责添加1x个部分类作为组织和重构代码的第一步是有益的。

这非常有帮助，因为它可以帮助使代码更具可读性，而不会实际影响执行行为。它还可以帮助确定何时易于重构某个职责，或者何时与其他方面紧密纠缠在一起。

然而，需要明确的是，这仍然是糟糕的代码，在开发结束时，您仍然希望每个类有一个职责(而不是每个分部类)。这只是一块垫脚石:)