扩展方法和源代码的前向兼容性

Question

我想解决在未来开发中使用扩展方法和类接口放大的问题（现在是假设的，但将来可能是真实的）。

示例：

/* the code written in 17. March 2010 */
public class MySpecialList : IList<MySpecialClass> {
    // ... implementation
}
// ... somewhere elsewhere ...
MySpecialList list = GetMySpecialList(); // returns list of special classes
var reversedList = list.Reverse().ToList(); // .Reverse() is extension method
/* now the "list" is unchanged and "reveresedList" has same items in reversed order */

/* --- in future the interface of MySpecialList will be changed because of reason XYZ*/

/* the code written in some future */
public class MySpecialList : IList<MySpecialClass> {
    // ... implementation
    public MySpecialList Reverse() {
        // reverse order of items in this collection
        return this;
    }
}
// ... somewhere elsewhere ...
MySpecialList list = GetMySpecialList(); // returns list of special classes
var reversedList = list.Reverse().ToList(); // .Reverse() was extension method but now is instance method and do something else !
/* now the "list" is reversed order of items and "reveresedList" has same items lake in "list" */

我的问题是：有什么方法可以防止这种情况（我没有找到）？如果现在有办法防止它，有什么方法可以找到这样可能的问题吗？如果现在如何找到可能的问题，我是否应该禁止使用扩展方法？

谢谢。

编辑：

你的回答很有用。 我可以找到代码中使用扩展方法的位置吗？和/或我可以找到代码中使用实例方法但存在具有相同签名的扩展方法的位置吗？

Answer 1

看起来您所描述的是以下情况

1. 在您的产品 MySpecialList 的 V1 中没有 Reverse 方法，因此对 Reverse 的所有调用都绑定到同名的扩展方法
2. 在产品的 V2 中，MySpecialList 获得了一个 Reverse 方法，现在所有以前对扩展方法的绑定都绑定到实例方法。

如果您想在实例/扩展方法形式中调用 Reverse，则无法阻止这种情况，因为这是设计的行为。如果实例方法至少与扩展方法版本一样好，则实例方法将始终优先于扩展方法。

100% 防止这种情况的唯一方法是将扩展方法作为静态方法调用。例如，

ExtensionMethods.Reverse(list);

与新版本产品绑定到新方法的问题不仅仅限于扩展方法（尽管问题可能更糟）。您可以对类型执行许多操作来改变方法绑定受影响的方式，例如实现新接口、继承或添加新转换

Answer 2

这就是我们编写单元测试的原因。

首先，编写扩展方法。准确地说出它们的名字。因此，有一天，如果扩展方法作为同名类上的真实方法实现，那么很有可能它会与您的扩展方法执行相同的操作，并且不会造成任何破坏。

其次，通过单元测试，您将很快看到什么出了问题，并追踪到它出了问题，因为扩展方法不再被调用，因为该类现在有一个具有该名称的自己的方法。鉴于此，您可以选择重命名方法，将扩展方法作为静态方法调用，或者重写代码以正确使用新方法。

Answer 3

保证这一点的唯一方法是为您的扩展方法指定唯一的名称。这可能很简单，只需在方法前加上您姓名缩写的前缀即可。我知道它看起来很难看，但 99.9% 的时间应该都能用。

Answer 4

在这个特定的实例中，我认为返回新的反向列表（而不是在适当的位置反转列表）的扩展方法首先不应该被称为“Reverse”，而应该是 getReversedList() 或类似的方法。

但是你的观点（关于无副作用的扩展方法无意中被引起副作用的本地方法取代）是有效的；命名约定可能是一个好方法，但是，是的，这是不要不加区别地使用扩展方法的原因（但不足以禁止它们）。