【发布时间】：2010-09-05 09:54:18
【问题描述】：
我已经看到这些被以各种方式使用，并被指控以错误的方式使用它们（尽管在那种情况下，我以这种方式使用它们来展示point）。
那么，您认为使用扩展方法的最佳做法是什么？
开发团队是否应该创建一个扩展方法库并将它们部署到各种项目中？
是否应该有一个开源项目形式的常用扩展方法集合？
更新：已决定创建一个组织范围的扩展方法库
【问题讨论】：
标签： .net
【发布时间】：2010-09-05 09:54:18
【问题描述】：
即将发布的第 2 版框架设计指南将对实现扩展方法提供一些指导，但总的来说：
您应该只定义“在语义上有意义的”扩展方法，并提供与每个实现相关的辅助功能。
您还应该避免扩展 System.Object，因为并非所有 .NET 语言都能够将扩展方法作为扩展调用。 （例如 VB.NET 需要将其作为静态扩展类的常规静态方法调用。）
除非您要扩展接口，否则不要在与扩展类型相同的命名空间中定义扩展方法。
不要定义与“真实”方法具有相同签名的扩展方法，因为它永远不会被调用。
【讨论】：
您可能想看看http://www.codeplex.com/nxl 和http://www.codeplex.com/umbrella，它们都是扩展方法库。我个人没有看过源代码，但我相信那里的人会给你一些好的指导。
【讨论】：
-
请注意，自 2008 年以来，所引用的项目似乎都没有任何进一步的开发活动。
我一直在 Utils 类中将我的扩展方法包含在我的核心库中，因为使用我的框架的人可能会发现这些方法很有用，但对于最终开发人员可能可以选择扩展的大规模部署方法库，我建议将所有扩展放入他们自己的命名空间，甚至他们自己的项目文件中，以便人们可以选择添加引用或 using 语句，或者只是在需要时添加，如下所示：
Core.Extensions.Base64Encode(str);
我的 Utils 课程是我在全世界最好的朋友，那是在扩展方法出现之前，它们只会帮助加强我们的关系。我会遵循的最大规则是让人们尽可能选择他们正在使用的扩展框架。
【讨论】：
自 1990 年代初以来，Objective-C 语言就有了“类别”；这些本质上与 .NET 扩展方法相同。在寻找最佳实践时，您可能希望了解 Objective-C（Cocoa 和 NeXT）开发人员围绕它们提出的经验法则。
Brent Simmons（Mac OS X 和 iPhone 的 NetNewsWire RSS 阅读器的作者）今天刚刚发布了关于他的 new style rules for the use of categories 的帖子，并且围绕该帖子有一些 discussion in the Cocoa community。
【讨论】：
我认为这取决于扩展方法的用途。
- 与项目的特定业务需求相关的扩展方法（无论它们是连接到基本数据类型还是自定义对象）不应包含在将分布在多个项目中的库中。
- 与基本数据类型（int、string 等）或具有更广泛应用的泛型相关的扩展方法可以打包并跨项目分发。
注意不要在全局范围内包含应用很少的扩展方法，因为它们只会阻塞智能感知并可能导致混淆和/或误用。
【讨论】：
-
嗯，是的。没错。但是应该有更具体的指导方针。 （例如，应该扩展对象类吗？）你应该扩展第三方库吗？
当我第一次发现扩展程序时，我真的过度使用和滥用了它们。
出于多种原因，我开始不再使用任何扩展方法。
上面 Scott 的博客链接中指出了我停止使用它们的一些原因，例如“在扩展您不拥有的类型之前三思而后行”。如果您无法控制要扩展的类型的源，如果源类型有一些添加/更改（例如将项目移动到更新的 .NET 版本），您将来可能会遇到问题/冲突。如果较新的 .NET 版本在类型上包含与您的扩展同名的方法，那么有人会受到打击。
我停止使用扩展方法的主要原因是，您无法通过阅读代码快速分辨出方法的来源以及“拥有”它的人。
仅阅读代码时，您无法判断该方法是扩展还是只是该类型的标准 NET API 方法。
智能感知菜单很快就会变得非常混乱。
【讨论】：