在 .Net 中使用扩展方法的最佳实践是什么？

Question

我已经看到这些被以各种方式使用，并被指责以错误的方式使用它们（尽管在那种情况下，我以这种方式使用它们来证明一点）。

那么，您认为使用扩展方法的最佳实践是什么？

开发团队是否应该创建一个扩展方法库并将它们部署到各种项目中？

是否应该有一个开源项目形式的通用扩展方法的集合？

更新：已决定创建一个组织范围的扩展方法库

Answer 1

即将发布的框架设计指南第2版将为实现扩展方法提供一些指导，但总的来说：

您应该只定义扩展方法“它们具有语义意义”并提供与每个实现相关的辅助功能。

您还应该避免扩展System.Object，因为并非所有.NET语言都能够将扩展方法作为扩展名调用。 （例如，VB.NET需要将其称为静态扩展类上的常规静态方法。）

除非您扩展接口，否则不要在与扩展类型相同的命名空间中定义扩展方法。

不要使用与“真实”方法相同的签名定义扩展方法，因为它永远不会被调用。

Answer 2

您可能需要查看http://www.codeplex.com/nxl和http://www.codeplex.com/umbrella这两个扩展方法库。 我个人还没有看过源代码，但我相信那些人能够给你一些好的指针。

Answer 3

我一直在Utils类中将我的扩展方法包含在我的Core库中，因为使用我的框架的人可能会发现这些方法很有用，但对于大规模部署，最终开发人员可能选择了扩展方法库，我建议将所有扩展放入他们自己的命名空间，甚至是他们自己的项目文件，以便人们可以选择添加引用或using语句，或者只是在需要的地方，如下所示：

Core.Extensions.Base64Encode(str);

My Utils课程是我在世界上最好的朋友，它是在扩展方法出现之前，它们只是帮助加强了我们的关系。 我将遵循的最大规则是让人们选择他们正在使用的扩展框架。

Answer 4

自20世纪90年代初以来，Objective-C语言已经有了“类别”; 这些与.NET扩展方法基本相同。 在寻找最佳实践时，您可能希望了解Objective-C（Cocoa和NeXT）开发人员已经提出了哪些经验法则。

Brent Simmons （适用于Mac OS X和iPhone的NetNewsWire RSS阅读器的作者）今天刚刚发布了关于他使用类别的新风格规则，并且在该帖子的Cocoa社区中进行了一些讨论 。

Answer 5

我认为这取决于Extension方法的用途。

• 与项目的特定业务需求相关的扩展方法（无论它们是否连接到基本数据类型或自定义对象）不应包含在将分布在多个项目中的库中。
• 与基本数据类型（int，string等）或具有更广泛应用程序的泛型相关的扩展方法可以跨项目打包和分发。

注意不要全局包含几乎没有应用的扩展方法，因为它们只会阻塞智能感知并导致混淆和/或误用。

Answer 6

当我第一次发现扩展时，我真的过度使用并滥用它们。

在很大程度上，由于多种原因，我已经开始放弃使用任何扩展方法。

我停止使用它们的一些原因在上面的Scott的博客链接中注明，例如“在扩展您不拥有的类型之前请三思而后行”。 如果您无法控制要扩展的类型的源，那么如果源类型有一些添加/更改（例如将项目移动到较新的.NET版本），将来可能会遇到问题/冲突。 如果较新的.NET版本包含与您的扩展名相同的类型的方法，则有人会遭到破坏。

我停止使用扩展方法的主要原因是你无法通过阅读方法源代码所在的代码以及“拥有”它来快速判断。

当只是阅读代码时，您无法分辨该方法是扩展还是只是该类型的标准.NET API方法。

intellisense菜单真的很快就会变得非常混乱。