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