框架类型的扩展方法的使用答案

【问题标题】：Usage of extension methods for framework types框架类型的扩展方法的使用
【发布时间】：2014-11-04 03:41:37
【问题描述】：

在一项新工作中，有人告诉我避免使用您（或您的组织）无法控制的类型的扩展方法，这意味着外部库、框架类型（如字符串、列表等）。

我得到的论点是，如果框架开发人员现在决定实现一个与您的扩展方法具有相同名称和/或参数的方法，这将是糟糕的。

虽然可能会出现这个问题，但这个论点有效地将扩展方法的可用性降低到几乎为零。这个论点会被认为是有效的吗？我不建议在任何地方都使用扩展方法，但我想知道支持和反对它的类似论据。

【问题讨论】：

如果您害怕，只需制定一个政策，在您的扩展方法名称前面加上一些东西。
我认为如果出现这种情况，编译器会警告你，与此同时，你将获得可读性，获得重用，并在使用时减少代码重复扩展方法来向您不控制的代码添加功能。
@jeffdot：不，编译器不会警告你。例如，我有一个扩展方法 CopyTo(this Stream source, Stream target) - 如果您针对 .NET 3.5 编译会调用它，但如果针对 .NET 4+ 编译则不会...
@JonSkeet 您可能刚刚说服我，我安装了一些第三方工具来为我提供这些工具。要去测试一下；谢谢。

【解决方案1】：

这是一个具有一些优点的论点，但在很多情况下，问题是可以避免的：

如果您控制自己的代码并且可以在必要时轻松更新它，那么您可以轻松编写单元测试来检测问题并在出现问题时纠正它。（我假设您在部署之前会验证对外部库的任何更新。）
如果您相信外部库开发人员会遵循正常的良好做法以实现向后兼容性，那么他们无论如何都不应该向 interfaces 添加成员，因为这会破坏现有的实现...所以您可以至少要为接口编写扩展方法。
如果您的扩展方法的名称非常不太可能添加到外部库中，那么实际上这不是问题。例如，如果你的公司写了 Frobulators，这是一个特定于你的术语，那么写
```
public static Frobulator ToFrobulator(this string Frobulator)
```
在现实中真的不会成为问题。

【讨论】：

【解决方案2】：

当然，风险是存在的，但是在您无法控制的封闭或sealed 类型上定义某些东西正是扩展方法的意义所在。如果您只在自己的类型上创建扩展方法，扩展方法的有效性（与常规方法相比）将被最小化。

在命名约定中有一个非常简单的“解决方案”。如果您使用特定标识符为扩展添加前缀或后缀，则可以确定 Microsoft 不会创建类似的方法。

【讨论】：