C＃で拡張メソッドを持つインターフェイスの代わりに抽象クラスを使用する場合

「抽象クラス」と「インターフェース」は類似した概念であり、インターフェースはより抽象的な概念です。1つの差別化要因は、抽象クラスが必要なときに派生クラスのメソッド実装を提供することです。ただし、C＃では、この差別化要因は、インターフェイスメソッドの実装を提供できる拡張メソッドの最近の導入によって削減されました。別の差別化要因は、クラスが1つの抽象クラスのみを継承できる（つまり、多重継承がない）が、複数のインターフェイスを実装できることです。これにより、インターフェイスの制限が緩和され、柔軟性が高まります。それでは、C＃では、拡張メソッドを備えたインターフェイスの代わりに抽象クラスをいつ使用すべきでしょうか？

インターフェイス+拡張メソッドモデルの注目すべき例はLINQです。ここではIEnumerable、多数の拡張メソッドを介して実装されるすべてのタイプに対してクエリ機能が提供されます。

クラスの一部を実装する必要がある場合。私が使用した最良の例は、テンプレートメソッドパターンです。

public abstract class SomethingDoer
{
    public void Do()
    {
        this.DoThis();
        this.DoThat();
    }

    protected abstract void DoThis();
    protected abstract void DoThat();
}

したがって、Do（）が呼び出されたときに実行されるステップを、それらの実装方法の詳細を知らなくても定義できます。派生クラスは抽象メソッドを実装する必要がありますが、Do（）メソッドは実装しないでください。

拡張メソッドは、必ずしも式の「クラスの一部である必要があります」部分を満たしているわけではありません。さらに、iirc、拡張メソッドはスコープ内でpublic以外のものにはなりません（表示されません）。

編集する

この質問は、私が最初にクレジットを与えたよりも興味深いものです。さらに調査すると、Jon Skeet は SOでこのような質問に答え、インターフェイス+拡張メソッドを使用することに賛成しました。また、潜在的な欠点は、この方法で設計されたオブジェクト階層に対するリフレクションを使用していることです。

個人的には、現在一般的な慣行を変更することの利点を理解するのに苦労していますが、それを行う上でのデメリットはほとんどありません。

ユーティリティクラスを介して多くの言語でこの方法でプログラムすることが可能であることに注意する必要があります。拡張機能は、メソッドをクラスに属しているように見せるための構文糖を提供するだけです。

それはあなたがモデル化したいものについてのすべてです：

抽象クラスは継承によって機能します。特別な基本クラスであるため、is-a -relationship をモデル化しています。

たとえば、犬は動物であるため、

class Dog : Animal { ... }

一般的な全動物を実際に作成するのは理にかなっていないため（どのように見えますか？）、このAnimal基本クラスを作成しますabstractが、それでも基本クラスです。そして、Dogクラスはなしで意味をなしませんAnimal。

一方、インターフェースは別の話です。それらは継承を使用しませんが、多相性を提供します（これも継承で実装できます）。彼らはis-a関係をモデル化していませんが、それ以上はサポートしています。

たとえば、別のIComparableオブジェクトとの比較をサポートするオブジェクトを使用します。

クラスの機能は、実装するインターフェースに依存しません。インターフェースは、機能にアクセスする一般的な方法を提供するだけです。私たちはまだそれらを実装させることなくDisposea Graphicsまたはaの可能性がありFileStreamますIDisposable。インタフェースだけに関する方法を一緒。

原則として、クラスの動作を変更せずに、拡張機能と同様にインターフェイスを追加および削除して、クラスへのアクセスを強化することができます。ただし、オブジェクトが無意味になるため、基本クラスを取り去ることはできません！

何年も抽象クラスを使用していない（少なくとも作成されていない）ことに気付きました。

抽象クラスは、インターフェイスと実装の間のやや奇妙な獣です。抽象クラスには、私のクモ感覚を刺すようなものがあります。私は、インターフェースの背後にある実装を何らかの方法で「公開」すべきではない、と主張します（または、提携します）。

インターフェイスを実装するクラス間で共通の動作が必要な場合でも、抽象クラスではなく、独立したヘルパークラスを使用します。

インターフェースに行きます。

私見、私はここに概念の混合があると思う。

クラスは特定の種類の継承を使用し、インターフェイスは異なる種類の継承を使用します。

両方の種類の継承は重要かつ有用であり、それぞれに長所と短所があります。

最初から始めましょう。

インターフェースに関する話は、C ++からさかのぼって始まります。1980年代半ば、C ++が開発されたとき、異なる種類のインターフェイスとしてのインターフェイスのアイデアはまだ実現していませんでした（やがて実現します）。

C ++には、クラスが使用する継承の一種である、実装継承と呼ばれる1種類の継承しかありませんでした。

GoF Bookの推奨事項「実装用ではなく、インターフェイス用にプログラムする」を適用できるようにするため、C ++は抽象クラスと複数の実装の継承をサポートし、C＃のインターフェイスでできること（そして役立つこと！） 。

C＃では、新しい種類のインターフェイス、新しい種類の継承、インターフェイス継承が導入され、「実装ではなくインターフェイス用にプログラミングする」をサポートするための少なくとも2つの異なる方法が提供されます。インターフェースの継承による多重継承をサポートします（実装の継承ではサポートしません）。

したがって、C＃のインターフェイスの背後にあるアーキテクチャ上の理由は、GoFの推奨事項です。

これが助けになることを願っています。

よろしく、ガストン

インターフェースに拡張メソッドを適用すると、共通のインターフェースのみを共有する可能性のあるクラスに共通の動作を適用するのに役立ちます。そのようなクラスはすでに存在し、他の手段を介して拡張機能に閉じられる場合があります。

新しい設計では、インターフェイスで拡張メソッドを使用することをお勧めします。型の階層の場合、拡張メソッドは、変更のために階層全体を開かずに動作を拡張する手段を提供します。

ただし、拡張メソッドはプライベート実装にアクセスできないため、階層の最上部で、パブリックインターフェイスの背後にプライベート実装をカプセル化する必要がある場合、抽象クラスが唯一の方法になります。

C＃では多重継承はサポートされていないと思うので、インターフェイスの概念がC＃で導入されたのはそのためです。

抽象クラスの場合、多重継承もサポートされていません。したがって、抽象クラスまたはインターフェースを使用するかどうかを決めるのは簡単です。

私は、C＃がインターフェイスの演算子（この場合は暗黙的な変換）をサポートしていないという理由だけで、プロジェクトに抽象クラスを実装するプロセスにいます。