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

我已经看到这些被用于每一种方式,并被指责使用他们错误的方式(虽然在那种情况下,我用他们的方式来演示一个 point )。

那么,您认为采用扩展方法的最佳实践是什么?

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

是否应该以开源项目的形式存在一组通用扩展方法?

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

0
额外 编辑
意见: 1

6 答案

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

Core.Extensions.Base64Encode(str);

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

0
额外

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

  • 与项目的特定业务需求相关的扩展方法(不管它们是连接到基本数据类型还是自定义对象)不应包含在分布在多个项目中的库中。
  • 与基本数据类型(int,字符串等)相关的扩展方法或具有更广泛应用程序的泛型可以跨项目打包和分发。

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

0
额外
嗯,是。那是对的。但是应该有更具体的指导方针。 (例如,是否应该扩展对象类?)您应该扩展第三方库吗?
额外 作者 Vaibhav,

您可能需要查看 http://www.codeplex.com/nxlhttp://www.codeplex.com/umbrella 它们都是扩展方法库。我个人没有看过源代码,但我相信那里的人可以给你一些好的指针。

0
额外
注意到自2008年以来,这两个参考项目似乎都没有进一步的开发活动。
额外 作者 DavidRR,

即将发布的框架设计指南第二版将为实施扩展方法提供一些指导,但一般来说:

你应该只定义扩展方法“它们在哪里产生语义”,并提供与每个实现相关的帮助函数。

你也应该避免扩展System.Object,因为并不是所有的.NET语言都能够将扩展方法作为扩展来调用。 (例如VB.NET需要将它作为静态扩展类中的常规静态方法调用。)

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

不要将具有相同签名的扩展方法定义为“真实”方法,因为它永远不会被调用。

0
额外

Theobjective-clanguage has had "Categories" since the early 1990s; these are essentially the same thing as .NET Extension Methods. When looking for best practices you might want to see what rules of thumbobjective-c(Cocoa & NeXT) developers have come up with around them.

Brent Simmons (the author of the NetNewsWire RSS reader for Mac OS X and iPhone) just posted today about his new style rules for the use of categories and there's been a bit of discussion in the Cocoa community around that post.

0
额外

当我第一次发现扩展时,我真的滥用和滥用了它们。

对于大多数情况,我已经开始放弃使用任何扩展方法。

我停止使用它们的一些原因在Scott上面的博客链接中提到,例如“在扩展你不拥有的类型之前考虑两次”。如果您无法控制要扩展的类型的源,那么如果源类型有一些添加/更改(如将项目移动到更新的.NET版本),您将来可能会遇到问题/冲突。如果较新的.NET版本包含与扩展名同名的类型的方法,则会有人遭到破坏。

我停止使用扩展方法的主要原因是,您无法通过阅读代码快速了解方法来源以及谁拥有它。

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

intellisense菜单真的很麻烦。

0
额外