指南 - 扩展方法 vs 部分类

Question

我们正在工作中就实体类的方法定义进行讨论，讨论的方式有两种：作为扩展方法或者使用局部类方式。我们讨论的方法类型不会修改实体状态，它们纯粹是“帮助器”方法，用于查询状态并返回值。

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

我没有太强烈的偏好，但很想知道其他人是否有偏好（或者知道哪种方式的文档指南）。

我开始写出了我所能想到的每种方法的优点列表，但最终我只得出了以下结果：

局部类

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

• 由于使用了partial关键字，打开实体类时，可以看到包含帮助器方法的其他文件的存在

扩展方法

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

还有其他人可以发表意见吗？

PS：我认为这不是以下问题的重复，因为那个问题的提问者满意于将概述功能差异的响应标记为正确答案，而没有回答此情况下哪种方法是最佳实践的问题： Partial Class vs Extension Method

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

- Ashby

Answer 1

在我看来，扩展方法有两个好处。首先，当你将它们应用到接口时，它会给你一种写抽象基类的错觉，让你定义一些公共方法，但更加灵活，因为一个类只能有一个基类，但可以实现多个接口。其次，如果你将它应用到普通类中，那么我倾向于将其视为某种黑客技巧。当原始类缺少某些方法，并且你真的感觉它们应该拥有这些方法，但它们不在你的掌握范围内时，你被迫在其他地方实现它们，作为实用程序方法，并给你一种幻觉，认为它实际上存在。

最终，这两种情况都只是语法糖，但对我来说，扩展接口更有意义，例如，只需查看LINQ的Enumerable类。我已经在数十个完全不同的类上使用了这些扩展方法，所以它确实很值得。一个类扩展方法的例子是，在它被添加到框架之前，我自己制作了string.IsNullOrWhitespace。

扩展接口似乎是正确的，因为接口定义了一个合同，你可以依靠该合同在你的扩展方法中，但当你扩展一个普通类时，它可能会改变并破坏你的扩展方法。当然，接口也可能会改变，但我认为它们往往更加深入地设计，但我没有任何统计数据。

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

部分类很酷，因为它们不像扩展方法那样大的黑客。它们不是语法糖，不是魔术。这只是处理自动生成的类的最佳和最简单的方法，所以我对此并不太在意。我写了一些代码生成器，它们会发出区域，供人类编写自己的内容，并且在后续的代码生成中不会被覆盖。这样更舒适，但仅此而已。我不能改变.NET工具如何生成代码，它们不是这样做的，因此部分类是下一个最好的选择。

总之，我的意见是只在必要时使用扩展方法，并尽可能使用部分类。

- fejesjoco

---

非常好的答案。感谢您的贡献！ - Ashby

Answer 2

我不知道为什么你会创建一个部分类，除非你的原始类已经超出了其目的。看一下你想要扩展的类，它们真的只做了一件事，还是做了很多事情。看一下单一职责原则（http://en.wikipedia.org/wiki/Single_responsibility_principle）。

如果你可以创建其他类可以利用的方法，我建议创建一个扩展类。它将扩展其他类的功能，使你的工具箱更加灵活。

- Espen Medbø

---

嗨emedbo，如先前所述，它们是实体类，所提出的方法仅是检索状态的辅助程序。因此，没有SRP的违规行为。这些方法是特定于此实体的，因此它们不能被泛化以供其他类使用。 - Ashby