c# - 指南 - 扩展方法与部分类

Question

我们正在讨论为实体类定义方法的最佳方式 - 作为扩展方法或使用分部类。我们讨论的这类方法不会修改实体的状态，它们是纯粹的“辅助”方法，可以查询状态并返回值。

这两种方法的主要好处是保持实体类干净，同时仍然为客户端代码提供智能感知支持。

我对这两种方式都没有强烈的偏好，但很想知道其他人是否对其中一种有偏好(或知道记录的指南)。

我开始为我能想到的每种方法写下优点列表，但最后我想到的是:

部分类

• 方法定义位于类中(即使它是另一个文件)，因此支持“查找方法”的 Visual Studio 工具(例如 resharper 中的 ALT-\)将定位该方法

• 由于使用了 partial 关键字，一旦实体类被打开，包含辅助方法的其他文件的存在就很明显

扩展方法

• 文件的命名(“entityNameExtension”)及其在项目中的位置(在“Extensions”子文件夹中)直观且易于搜索

其他人可以对此发表意见吗？

PS 我不认为这是以下问题的重复，因为该问题的提问者满足于将概述功能差异的回复标记为正确答案，但未回答有关哪种方法的问题是这种情况下的最佳做法: Partial Class vs Extension Method

编辑 - 我正在寻找人们对一种方法或另一种方法的偏好，因为我们找不到针对这种特定情况的文档化指南。这两种方法都是可能的，并且都不违反任何设计原则，所以这是一个偏好问题，我想知道你的。

Answer 1

在我看来，扩展方法有两个好处。首先，当你将它们应用到接口(interface)上时，会给你一种写抽象基类的错觉，让你定义一些常用的方法，但它更灵活，因为一个类只能有一个基类，但可以实现多个接口(interface)。其次，如果你将它应用到常规类(class)中，那么我倾向于将其视为某种黑客攻击。当原始类缺少一些方法时，你真的觉得他们应该有这些方法，但他们没有，而且你也够不到，所以你不得不在其他地方实现它们，作为实用方法，它给出了你错觉它真的在那里。

这两种情况最终都只是语法糖，但扩展接口(interface)对我来说更有意义，例如，如果我只看 LINQ 的 Enumerable 类。我已经在几十个完全不同的类上使用了这些扩展方法，所以它确实得到了返回。类扩展方法的一个示例是在将其添加到框架之前创建自己的 string.IsNullOrWhitespace。

扩展接口(interface)似乎是正确的，因为接口(interface)定义了一个契约，你可以在你的扩展方法中依赖那个契约，但是当你扩展一个常规类时，它可能会改变并破坏你的扩展方法。当然，界面也可能会发生变化，但我认为它们往往设计得更彻底，但我没有任何统计数据。

然后是面向对象编程的情况。你觉得你的方法应该去哪里，谁使用这些额外的方法，边界在哪里。如果你认为一个方法属于一个类，那么就把它放在类中。有道理，很简单。在发明扩展方法之前，人们编写了非常好的类，他们把一切都放在了它所属的地方，生活很美好，哈哈。

部分类很酷，因为它们不像扩展方法那么复杂。它们不是语法糖，也不是魔法。这只是处理自动生成类的最好和最简单的方法，所以我没有想太多。我已经编写了一些代码生成器，它们会发出人类可以编写自己的东西的区域，并且不会在后续代码生成中被覆盖。那样比较舒服，但仅此而已。我无法更改 .NET 工具生成代码的方式，它们也不会这样做，因此分部类是下一个最好的选择。

总而言之，我的观点是只在真正需要时才使用扩展方法，并尽可能使用分部类。