c# - 对于封装和可重用性，首选扩展方法？

Question

edit4:讲究了，因为这似乎更多地变成了讨论，而不是特定的问题。
在C++编程中，通常最好的做法是“首选非成员非友函数”而不是实例方法。 Scott Meyers在this classic Dr. Dobbs article中推荐了此方法，Herb Sutter和Andrei Alexandrescu在C++ Coding Standards中重复了这一点(项目44)；一般的论点是，如果一个函数可以仅依靠类公开的公共(public)接口(interface)来完成其工作，则实际上它增加了封装使其具有外部性。虽然这在某种程度上使类的“打包”感到困惑，但通常认为这样做是值得的。
现在，自从我开始使用C#编程以来，我一直感觉到在这里是他们试图通过“属于非成员，非 friend 功能的一部分”实现的概念的最终表达。类接口(interface)”。 C#向混合添加了两个关键组件-第一个是interfaces，第二个是extension methods:

接口(interface)允许类正式指定其公共(public)合约，它们要向世人展示的方法和属性。

任何其他类都可以选择实现相同的接口(interface)并履行相同的契约(Contract)。

扩展方法可以在接口(interface)上定义，向所有实现者自动提供可以通过该接口(interface)实现的任何功能。

最重要的是，由于有“实例语法”糖和IDE支持，因此可以像调用其他任何实例方法一样调用它们，从而消除了认知开销!

因此，借助成员的便利性，您可以获得“非成员，非 friend ”功能的封装优势。在我看来，两全其美。 .NET库本身在LINQ中提供了一个出色的示例。但是，在我看来，到处都可以看到有人警告不要扩展方法。甚至MSDN页面本身也指出:

In general, we recommend that you implement extension methods sparingly and only when you have to.

(编辑:)即使在当前的.NET库中，我也可以看到具有扩展而不是实例方法的扩展很有用的地方-例如，List<T>的所有实用功能(Sort，BinarySearch，FindIndex等。)如果将其提升为IList<T>，将非常有用-获得类似的免费红利功能，将为实现该接口(interface)带来更多好处。)
那么判决是什么？扩展方法是封装和代码重用的顶峰，还是我只是在欺骗自己？
( edit2:)作为对Tomas的回应-尽管C#最初是从Java的OO心态开始的，但似乎每个新版本都采用了更多的多范式编程；这个问题的主要目的是是否使用扩展插入样式改变的方法(朝着更通用/功能更强的C#)有用或值得。
edit3:可覆盖的扩展方法
到目前为止，使用这种方法唯一真正的问题是，如果需要的话，您不能专门研究扩展方法。我一直在考虑这个问题，并且我想出了一个解决方案。
假设我有一个接口(interface)MyInterface，我想扩展它-
我在MyExtension静态类中定义扩展方法，并将其与另一个接口(interface)配对，称为MyExtensionOverrider。 MyExtension方法是根据以下模式定义的:

public static int MyMethod(this MyInterface obj, int arg, bool attemptCast=true)
{
    if (attemptCast && obj is MyExtensionOverrider)
    {
        return ((MyExtensionOverrider)obj).MyMethod(arg);
    }
    // regular implementation here
}

覆盖接口(interface)反射(reflect)了MyExtension中定义的所有方法，但没有this或attemptCast参数的情况除外:

public interface MyExtensionOverrider
{
    int MyMethod(int arg);
    string MyOtherMethod();
}

现在，任何类都可以实现该接口(interface)并获得默认的扩展功能:

public class MyClass : MyInterface { ... }

任何想要通过特定实现覆盖它的人都可以实现覆盖接口(interface):

public class MySpecializedClass : MyInterface, MyExtensionOverrider
{
    public int MyMethod(int arg) 
    { 
        //specialized implementation for one method
    }
    public string MyOtherMethod() 
    {   // fallback to default for others
        MyExtension.MyOtherMethod(this, attemptCast: false); 
    }
}

然后我们开始:接口(interface)上提供的扩展方法，并在需要时选择完全可扩展的选项。同样完全通用，接口(interface)本身也不需要知道扩展名/替代项，并且可以实现多个扩展名/替代对而不会互相干扰。
我可以看到这种方法的三个问题-

有点脆弱-扩展方法和重写接口(interface)必须手动保持同步。

有点丑陋-实现覆盖接口(interface)涉及到您不想专门化的每个功能的样板。

有点慢-在每个方法的主线中都有一个额外的bool比较和强制转换尝试。

尽管如此，尽管如此，我认为这是我们能够获得的最好的解决方案，直到对接口(interface)功能的语言支持为止。有什么想法吗？

Answer 1

我通常喜欢扩展方法，尤其是在接口(interface)上，但是它们有两个问题:

首先，如果实现具有实现扩展方法目的的更有效方法，则没有通用的表达方式。例如，Enumerable.Count()明确知道ICollection/ICollection<T>并对其进行特殊处理。一种替代方法是，如果接口(interface)实际上可以直接包含实现，而仅引用其他接口(interface)方法而不声明字段。然后可以在适当的实现中覆盖这些方法。当然，这确实意味着您需要拥有接口(interface)。但是在某些情况下，它比当前的扩展方法更干净。 (通过避免引入字段的能力，我相信您会遇到一些实现问题，这些问题会引入类的多重继承。)

第二，我不喜欢扩展方法的发现方式。不能说“我想要类X的扩展方法”而不用将同一 namespace 中其他类的扩展方法拖入。我希望你能写:

using static System.Linq.Enumerable;

只选择那些扩展方法。

(顺便说一句，我将在周四的NDC 2010上更多地讨论这两个方面。希望这次谈话能被记录下来。)

指定仅依赖公共(public)接口(interface)的通用算法的能力很好。在提供接口(interface)的类型上调用这些算法的能力很好。当前的机制只是有一些尖锐的角落。

顺便说一句，能够在一个类型中编写方法，但是说:“限制我只能使用公共(public)API”，这可能会很好。