我已经看到它们以各种方式被使用，并且被指控以错误的方式使用它们(尽管在这种情况下，我是以那种方式来使用它们来说明观点)。

那么，我们认为采用扩展方法的最佳实践是什么？

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

是否应该以开源项目的形式收集一些通用的扩展方法？

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

解决方案

回答

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

• 与项目的特定业务需求相关的扩展方法(无论它们是否连接到基本数据类型或者自定义对象)都不应包含在将在多个项目中分布的库中。
• 与基本数据类型(int，字符串等)或者具有更广泛应用的泛型相关的扩展方法可以打包并分布在各个项目中。

注意不要在全局范围内使用几乎没有应用的扩展方法，因为它们只会阻塞智能感知，并可能导致混乱和/或者误用。

回答

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

Core.Extensions.Base64Encode(str);

我的Utils课是我在全世界最好的朋友，那是在推广方法问世之前，它们只有助于加强我们的关系。我要遵循的最大原则是让人们在可能的情况下选择使用哪种扩展框架。

回答

我们可能想看看同时都是扩展方法库的http://www.codeplex.com/nxl和http://www.codeplex.com/umbrella。我个人没有看过源代码，但是我敢肯定那里的人能够为我们提供一些很好的指导。

回答

自1990年代初以来，Objective-C语言就拥有"类别"；这些本质上与.NET扩展方法相同。当寻找最佳实践时，我们可能想看看Objective-C(Cocoa＆NeXT)开发人员提出了哪些经验法则。

Brent Simmons(用于Mac OS X和iPhone的NetNewsWire RSS阅读器的作者)今天发布了关于他使用类别的新样式规则的文章，可可社区对此话题进行了一些讨论。

回答

即将发布的第二版《框架设计指南》将提供一些有关实施扩展方法的指南，但总的来说：

我们只应在"有意义的地方"定义扩展方法，并提供与每个实现相关的辅助功能。

我们还应该避免扩展System.Object，因为并非所有.NET语言都可以将扩展方法作为扩展调用。 (例如，VB.NET将需要作为静态扩展类上的常规静态方法来调用它。)

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

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