インターフェイスと同じ名前空間の拡張メソッドを使用すると、10の異なるクラスで同じインターフェイスを同じ方法で実装する重複コードを用意する必要がないという点で、多重継承と同様の効果が得られると考えていました。
これを行うことの欠点は何ですか？私は長所はかなり明白だと思います、それは通常後であなたを噛むために戻ってくる短所です。
私が見ている短所の1つは、拡張メソッドを仮想化できないことです。そのため、すべてのインスタンスで同じ方法で拡張メソッドを実際に実装する必要があることを確認する必要があります。
拡張メソッドを介してインターフェイス機能を構築する際に見られる問題は、実際にはインターフェイスを実装していないため、オブジェクトをインターフェイスタイプとして使用できないことです。
IBar型のオブジェクトを受け取るメソッドがあるとします。拡張メソッドを介してクラスFooにIBarインターフェイスを実装すると、FooはIBarから派生せず、IBarと互換的に使用できません（リスコフの置換原則）。確かに、Fooに追加したい動作は得られますが、最初にインターフェイスを作成するという最も重要な側面を失います。さまざまなクラスでさまざまな方法で実装できる抽象的なコントラクトを定義できるため、依存クラスは、具体的な実装について知る必要はありません。
多重継承が必要な場合（そして今のところそれなしで生きてきた場合）、コードの重複を最小限に抑えるために、代わりに合成を使用すると思います。
これについて考える適切な方法は、インスタンス メソッドはオブジェクトによって行われるものであり、拡張メソッドはオブジェクトに対して行われるものであるということです。フレームワーク デザイン ガイドラインでは、可能な限りインスタンス メソッドを実装する必要があると述べています。
インターフェイスは、「この機能を使用することに関心がありますが、それがどのように達成されるかは気にしません」と宣言します。これにより、実装者は方法を自由に選択できます。これは、パブリック API であるインテントを、具体的なコードを持つクラスであるメカニズムから分離します。
これがインターフェイスの主な利点であるため、それらを完全に拡張メソッドとして実装すると、その目的が無効になるようです。IEnumerable<T>インスタンスメソッドもあります。
編集：また、オブジェクトは、含まれるデータに作用することを意図しています。拡張メソッドは、オブジェクトのパブリック API しか見ることができません (静的メソッドであるため)。オブジェクトを機能させるには、オブジェクトの状態をすべて公開する必要があります (オブジェクト指向ノーノー)。