最近我在考虑一个类，因为它的方法太多，所以看起来很胖。
遗留代码...
这有许多业务逻辑方面的方法在各种“Etntities”上执行所有类型的 CRUD。
我在想
问题： 你能列出这种重构的利弊吗，即把一个胖的具体类变成一个部分类，然后把它分解成更苗条的部分类？
【问题讨论】：
标签： c# .net refactoring partial-classes
我能想到的一个专业人士是减少源代码管理中的冲突/合并。您将减少并行签出的数量以及在开发人员签入他们的工作时总是出现的合并难题。我认为，如果您有许多开发人员经常在同一个课程上工作，那么我认为这是一个大专业人士。
【讨论】：
我认为您只是在谈论处理课程的简单性。性能或行为的优缺点不应该是因为编译时它应该产生相同的结果：
可以将类或结构或接口的定义拆分为两个或多个源文件。每个源文件都包含一个类定义部分，并且在编译应用程序时将所有部分组合在一起。
现在回答我能想到的利弊（仅关于简单性）：
我会去重构。特别考虑到 IDE 提供的所有功能，您只需单击 F12（或任何其他键）即可转到方法，而不是打开文件。
【讨论】：
将一个大类拆分为部分类可能在短期内让生活更轻松，但这并不是解决您的类所遇到的代码膨胀问题的合适解决方案。
根据我的经验，拆分现有大类给您带来的唯一好处是，在与其他开发人员一起处理该类时，更容易避免不断合并代码。但是，您仍然存在将不相关的功能打包到一个类中的核心问题。
最好将分解为部分类作为完整重构的第一步。如果您能够轻松地将相关方法和成员提取到它们自己的部分类中（而不破坏任何东西），那么您可以以此为基础创建完全独立的类并重新考虑它们之间的关系。
编辑：我应该澄清一下，这个建议是在假设您的遗留代码在一个类中具有不相关的功能的情况下给出的，因为多年来“只需在此处添加一种方法”。将功能分布在部分类中是有真正的原因的，例如，我之前处理过代码，在一个文件中有一个非常大的接口，但随后根据产品功能的区域将所有方法分组到部分类中——这我觉得还可以。
【讨论】：
我会说 Partial 类将有助于维护代码，并且当我们有遗留代码以避免参考方面的更多更改时会更有帮助。稍后将有助于轻松重构
【讨论】：
如果您担心如何重构一个类，我建议您阅读SOLID 设计原则。
我认为你应该关注单一责任原则（SOLID 中的 S），它规定一个对象应该只有一个责任。
我认为我的回答并不是直接回答您的问题，使用分部类是否对您有益，但我相信如果您专注于 SOLID 设计原则，至少应该会给您一些关于如何组织代码的想法。
【讨论】：
我仅将部分类视为扩展类的一种方式，该类的代码已生成（并且可以随时重新生成），您希望在不覆盖自定义代码的情况下对其进行扩展。例如，您可以通过 Form 生成的代码和 Entity Framework DbContext 生成的代码看到这一点。
重构大型遗留类可能应该通过将单个职责分组并分离到单独的类中来完成。
【讨论】：