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

Question

我已经看到这些被用于各种方式，并且被指责以错误的方式使用它们（尽管在那种情况下，我使用它们来演示point）。

那么，您认为采用扩展方法的最佳做法是什么？

开发团队是否应该创建扩展方法库并在各种项目中进行部署？

是否应该以开源项目的形式收集常见的扩展方法？

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

Answer 1

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

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

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

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

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

Answer 2

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

Answer 3

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

Core.Extensions.Base64Encode(str);

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

Answer 4

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

Brent Simmons（适用于Mac OS X和iPhone的NetNewsWire RSS阅读器的作者）今天刚刚发布了关于他new style rules for the use of categories的帖子，并且该帖子周围有discussion in the Cocoa community点。

Answer 5

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

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

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

Answer 6

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

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

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

我停止使用扩展方法的主要原因是你无法通过阅读代码来源的代码和“拥有”它来快速告诉。

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

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