框架类型的扩展方法的用法

Question

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

我得到的论据是，如果框架开发人员现在决定实现与扩展方法具有相同名称和/或参数的方法，那将是不好的。

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

Answer 1

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

• 如果您控制代码并可以根据需要轻松地对其进行更新，则可以轻松编写单元测试以检测问题并在出现问题时进行纠正。 （我认为您无论如何都要先对外部库进行任何更新，然后再进行部署。）
• 如果您信任外部库开发人员遵循向后兼容的常规良好做法，那么他们无论如何都不应在接口中添加成员，因为那样会破坏现有的实现方式，因此您至少可以为接口编写扩展方法。

• 如果您的扩展方法有这将是不太可能的名字被添加到外部库，然后实际来看这不是一个问题。 例如，如果您的公司写的是Frobulators，而这是您特有的术语，那么请写

   public static Frobulator ToFrobulator(this string Frobulator) 

  实际上，这实际上不会成为问题。

Answer 2

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

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