Question

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

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

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

Answer 1

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

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

Answer 2

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

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