在.Net中使用扩展方法的最佳做法是什么？
我曾经看到过这些东西被用到了每一个方面，并被指责用错了方式（尽pipe在那种情况下，我是用这种方式来certificate一个观点的 ）。
那么，您认为采用扩展方法的最佳做法是什么？
开发团队是否应该创build一个扩展方法库并将其部署到各个项目中？
是否应该有一个开源项目forms的通用扩展方法集合？
更新：已决定创build一个组织广泛的扩展方法库
即将发布的“框架devise指南”第二版将为实施扩展方法提供一些指导，但总的来说：
你只应该定义扩展方法“在哪里做语义”，并提供与每个实现相关的帮助函数。
你也应该避免扩展System.Object，因为并不是所有的.NET语言都能够把扩展方法作为扩展。 （例如，VB.NET需要将其作为静态扩展类中的常规静态方法调用。
除非扩展接口，否则不要在与扩展types相同的名称空间中定义扩展方法。
不要将具有相同签名的扩展方法定义为“真实”方法，因为它永远不会被调用。
你可能想看一下http://www.codeplex.com/nxl和http://www.codeplex.com/umbrella这两个扩展方法库。; 我个人没有看过源代码，但我敢肯定，那里的家伙将能够给你一些好的指针。
我已经把我的扩展方法和我的Core库包含在Utils类中，因为使用我的框架的人可能会发现这些方法是有用的，但是对于最终开发人员可以select扩展方法库的大规模部署，我build议把所有的扩展插入自己的命名空间，甚至是自己的项目文件，这样人们可以select添加一个引用或者使用语句，或者只需要在需要的地方添加，就像这样：
Core.Extensions.Base64Encode(str); 我的公用事业class是我全世界最好的朋友，只是在延伸方法出现之前，他们只是帮助加强了我们的关系。 我要做的最大的规则是让人们select他们正在使用的扩展框架。
Objective-C语言自20世纪90年代初以来就有了“类别” 这些与.NET扩展方法基本相同。 在寻找最佳实践时，您可能想看看Objective-C（Cocoa和NeXT）开发人员在他们周围提出了哪些经验法则。
Brent Simmons （NetNewsWire RSS阅读器的作者，Mac OS X和iPhone）今天刚刚发布了他关于类别使用的新样式规则，围绕该职位的Cocoa社区进行了一些讨论 。
我认为这取决于扩展方法的用途。
- 与项目的特定业务需求相关的扩展方法（不pipe它们是连接到基本数据types还是自定义对象）都不应包含在分布在多个项目中的库中。
- 与基本数据types（int，string等）相关的扩展方法或具有更广泛应用的generics可以在项目中打包和分发。
注意不要在全球范围内包含几乎没有应用的扩展方法，因为它们只会阻塞智能感知，并可能导致混淆和/或滥用。
当我第一次发现扩展时，我真的滥用和滥用了它们。
在很大程度上，我已经开始摆脱使用任何扩展方法的原因有很多。
我停止使用它们的一些原因在Scott上面的博客链接中有记载，例如“在扩展你不拥有的types之前先考虑一下”。 如果您无法控制要扩展的types的源，那么如果源types有一些添加/更改（例如，将项目移动到更新的.NET版本），则可能会在将来遇到问题/冲突。 如果较新的.NET版本包含与扩展名同名的types的方法，则会有人被破坏。
我停止使用扩展方法的主要原因是，你不能通过阅读代码的方法来快速判断方法的来源以及谁拥有它。
当读完代码时，您无法判断方法是扩展还是只是一种标准的.NET API方法。
智能菜单真的很麻烦。
