使FAT类成为局部类的优点和缺点是什么?把它分成部分类

我能想到的一个好处是减少了源代码控制中的冲突/合并。您将减少并行签出的数量，以及在开发人员签入他们的工作时总是出现的合并头痛。我认为，如果你有许多开发者经常致力于同一个职业，这是一个很大的优势。

我认为你只是在谈论处理类的简单性。性能或行为的优缺点不应该是一样的，因为编译时应该生成相同的结果:

可以将类、结构或接口的定义拆分为两个或多个源文件。每个源文件都包含类定义的一部分，并且在编译应用程序时将所有部分组合在一起。

现在回答我能想到的利弊(只关于简单性):

• Pro:如果在团队中工作，冲突/合并更少。
• Pro:更容易搜索类中的代码。
缺点:你需要知道哪个文件处理每个代码，否则它会变得有点烦人。

我会选择重构。特别是考虑到IDE提供的所有功能，您只需单击F12(或任何其他键)即可转到方法，而不是打开文件。

将一个大的类拆分为部分类可能会在短期内使生活更容易，但这并不是解决类所经历的代码膨胀的真正合适的解决方案。

从我的经验来看，将现有的大型类拆分给您的唯一好处是，当与其他开发人员在该类上工作时，更容易避免不断合并代码。但是，您仍然存在将不相关的功能打包到一个类中的核心问题。

最好将分解为部分类作为完整重构的第一步。如果你能够轻松地将相关的方法和成员提取到它们自己的部分类中(而不破坏任何东西)，那么你可以将其作为创建完全独立类的基础，并重新考虑它们之间的关系。

编辑:我应该澄清一下，这个建议是在假设您的遗留代码在一个类中具有不相关的功能的情况下给出的，因为多年来"只需在这里添加一个方法"。将功能分散在部分类中是有真正的原因的，例如，我以前做过的代码在一个文件中有一个非常大的接口，但随后根据产品功能的领域将所有方法分组到部分类中——我认为这很好。

我认为部分类将有助于维护代码，当我们有遗留代码时将更有帮助，以避免在引用端进行更多更改。以后将有助于轻松地重构

如果你关心如何重构一个类，我建议你阅读SOLID设计原则。

我认为你应该关注单一职责原则(SOLID中的S)，它规定一个对象应该只有一个职责。

我想我的答案并不是直接回答你的问题，使用部分类是否对你有益，但我相信，如果你专注于SOLID设计原则，至少应该给你一些关于如何组织代码的想法。

我认为部分类只是作为扩展类的一种方式，您希望在不覆盖自定义代码的情况下扩展生成的代码(并且可以随时重新生成)。例如，您可以在表单生成代码和实体框架DbContext生成代码中看到这一点。

重构一个大的遗留类可能应该通过分组和分离单个职责到单独的类来完成。