抽象クラス/メソッドは廃止されていますか？

以前は、多くの抽象クラス/メソッドを作成していました。その後、インターフェイスの使用を開始しました。

現在、インターフェイスが抽象クラスを廃止していないかどうかはわかりません。

完全に抽象クラスが必要ですか？代わりにインターフェースを作成してください。いくつかの実装を含む抽象クラスが必要ですか？インターフェイスを作成し、クラスを作成します。クラスを継承し、インターフェイスを実装します。追加の利点は、一部のクラスが親クラスを必要とせず、インターフェイスを実装するだけであることです。

それでは、抽象クラス/メソッドは廃止されていますか？

いや

インターフェイスは、デフォルトの実装、抽象クラス、およびメソッドを提供できません。これは、多くの場合、コードの重複を避けるのに特に役立ちます。

これは、シーケンシャルカップリングを減らすための非常に良い方法でもあります。抽象メソッド/クラスがないと、テンプレートメソッドパターンを実装できません。このウィキペディアの記事をご覧になることをお勧めします：http : //en.wikipedia.org/wiki/Template_method_pattern

抽象メソッドが存在するため、基本クラス内から呼び出すことができますが、派生クラスで実装できます。基本クラスは次のことを知っています。

public void DoTask()
{
    doSetup();
    DoWork();
    doCleanup();
}

protected abstract void DoWork();

これは、派生クラスがセットアップおよびクリーンアップアクティビティを認識していなくても、中間パターンにホールを実装するための合理的な方法です。抽象メソッドがなければ、派生クラスを実装DoTaskしbase.DoSetup()、base.DoCleanup()常に呼び出すことを忘れないでください。

編集

また、実際に名前を知らなくても上記で説明したTemplate Method Patternへのリンクを投稿してくれたdeadalnixに感謝します。:)

いいえ、廃止されていません。

実際、抽象クラス/メソッドとインターフェースの間には、あいまいですが根本的な違いがあります。

これらのいずれかを使用する必要があるクラスのセットに共通の動作（関連クラス、つまり）がある場合は、抽象クラス/メソッドに進みます。

例：クラーク、オフィサー、ディレクター-これらのクラスはすべて、CalculateSalary（）が共通であり、抽象基本クラスを使用します。CalculateSalary（）は異なる方法で実装できますが、GetAttendance（）など、基本クラスで共通の定義を持つものもあります。

クラスの間に共通（選択されたコンテキスト内の無関係なクラス）が何もないが、実装が大きく異なるアクションがある場合は、インターフェイスに進みます。

例：牛、ベンチ、車、テレスコープではなく関連クラスですが、Isortableを使用してそれらを配列に並べ替えることができます。

多相的な観点からアプローチする場合、この違いは通常無視されます。しかし、私は個人的には、上記で説明した理由により、一方が他方よりも適切な状況があると感じています。

他の良い答えに加えて、インターフェイスと抽象クラスには基本的な違いがあります。誰も特に言及していません。つまり、インターフェイスは信頼性がはるかに低いため、抽象クラスよりもはるかに大きなテスト負荷を課します。たとえば、次のC＃コードを考えます。

public abstract class Frobber
{
    private Frobber() {}
    public abstract void Frob(Frotz frotz);
    private class GreenFrobber : Frobber
    { ... }
    private class RedFrobber : Frobber
    { ... }
    public static Frobber GetFrobber(bool b) { ... } // return a green or red frobber
}

public sealed class Frotz
{
    public void Frobbit(Frobber frobber)
    {
         ...
         frobber.Frob(this);
         ...
    }
}

テストする必要があるコードパスは2つだけであることが保証されています。Frobbitの作成者は、フロバーが赤または緑であるという事実に頼ることができます。

代わりに言う場合：

public interface IFrobber
{
    void Frob(Frotz frotz);
}
public class GreenFrobber : IFrobber
{ ... }
public class RedFrobber : Frobber
{ ... }

public sealed class Frotz
{
    public void Frobbit(IFrobber frobber)
    {
         ...
         frobber.Frob(this);
         ...
    }
}

私は今、そこでのFrobへの呼び出しの影響についてまったく何も知りません。私は確かFrobbitのすべてのコードはに対して堅牢であることをする必要がIFrobberのいずれかの可能な実装している人であっても実装無能（悪い）、または積極的に私や私のユーザーへの敵対的（はるかに悪いです）。

抽象クラスを使用すると、これらの問題をすべて回避できます。それらを使用してください！

あなたは自分でそれを言う：

いくつかの実装を含む抽象クラスが必要ですか？インターフェイスを作成し、クラスを作成します。クラスを継承し、インターフェイスを実装します

「抽象クラスを継承する」と比較すると、多くの作業が必要です。「純粋主義」の視点からコードにアプローチすることで、自分で仕事をすることができますが、実際の利益のためにワークロードに追加しようとせずに、すでに十分なことがあります。

@deadnixの投稿でコメントしたように、部分的な実装は、テンプレートパターンが形式化するという事実にもかかわらず、アンチパターンです。

このウィキペディアのテンプレートパターンの例に対するクリーンなソリューション：

interface Game {
    void initialize(int playersCount);
    void makePlay(int player);
    boolean done();
    void finished();
    void printWinner();
}
class GameRunner {
    public void playOneGame(int playersCount, Game game) {
        game.initialize(playersCount);
        int j = 0;
        for (int i = 0; !game.finished(); i++)
             game.makePlay(i % playersCount);
        game.printWinner();
    }
} 
class Monopoly implements Game {
     //... implementation
}

このソリューションは、inheritanceではなく構成を使用するため、より優れています。テンプレートパターンは、モノポリールールの実装とゲームの実行方法の実装との間に依存関係を導入します。ただし、これらはまったく異なる2つの責任であり、それらを結合する正当な理由はありません。

いいえ。提案された代替手段でさえ、抽象クラスの使用を含みます。さらに、言語を指定しなかったので、先に進み、汎用コードはいずれにしても脆弱な継承よりも優れたオプションであると言います。抽象クラスには、インターフェースよりも大きな利点があります。

抽象クラスはインターフェースではありません。それらはインスタンス化できないクラスです。

完全に抽象クラスが必要ですか？代わりにインターフェースを作成してください。いくつかの実装を含む抽象クラスが必要ですか？インターフェイスを作成し、クラスを作成します。クラスを継承し、インターフェイスを実装します。追加の利点は、一部のクラスが親クラスを必要とせず、インターフェイスを実装するだけであることです。

しかし、その後、あなたは非抽象的な役に立たないクラスを持つことになります。基本クラスの機能ホールを埋めるには、抽象メソッドが必要です。

たとえば、このクラスが与えられた場合

public abstract class Frobber {
    public abstract void Frob();

    public abstract boolean IsFrobbingNeeded { get; }

    public void FrobUntilFinished() {
        while (IsFrobbingNeeded) {
            Frob();
        }
    }
}

どちらFrob()も持たないクラスにこの基本機能をどのように実装しIsFrobbingNeededますか？

私は、抽象クラスが重要な役割を果たすサーブレットフレームワークの作成者です。さらに言えば、50％の場合にメソッドをオーバーライドする必要があり、そのメソッドがオーバーライドされなかったというコンパイラーからの警告を表示したい場合、セミ抽象メソッドが必要です。注釈を追加する問題を解決します。質問に戻りますが、抽象クラスとインターフェースには2つの異なるユースケースがあり、これまでのところ誰も時代遅れではありません。

インターフェースに時代遅れになるとは思わないが、戦略パターンに時代遅れになるかもしれない。

抽象クラスの主な用途は、実装の一部を延期することです。「クラスの実装のこの部分は異なるものにすることができます」と言います。

残念ながら、抽象クラスは、クライアントにinheritanceを介してこれを行わせます。一方、戦略パターンを使用すると、継承なしで同じ結果を得ることができます。クライアントは常に独自のクラスを定義するのではなく、クラスのインスタンスを作成できます。クラスの「実装」（動作）は動的に変化する可能性があります。戦略パターンには、設計時だけでなく実行時にも動作を変更できるという追加の利点があり、関係するタイプ間のカップリングが大幅に弱くなります。

私は一般的に、ABCよりも純粋なインターフェースに関連する保守問題にはるかに多く直面しています。YMMV-知らない、多分私たちのチームはそれらを不適切に使用しただけかもしれません。

そうは言っても、現実世界の類推を使用する場合、機能と状態がまったくない純粋なインターフェースにはどれほどの用途がありますか？USBを例として使用すると、これはかなり安定したインターフェイスです（現在USB 3.2になっていると思いますが、下位互換性も維持しています）。

しかし、それはステートレスなインターフェースではありません。機能が欠けているわけではありません。これは、純粋なインターフェースというよりは抽象基本クラスに似ています。実際には、非常に具体的な機能および状態の要件を持つ具体的なクラスに近く、ポートにプラグインする部分のみが代替可能な部分であるという抽象化のみがあります。

それ以外の場合は、標準化されたフォームファクターとはるかに緩やかな機能要件を備えたコンピューターの「穴」になり、すべてのメーカーがその穴に何かをさせる独自のハードウェアを思い付くまでは何もしません。それははるかに弱い標準になり、「穴」と何をすべきかの仕様に過ぎませんが、それを行う方法の中心的な規定はありません。一方、すべてのハードウェアメーカーが独自の方法で機能と状態をその「穴」にアタッチしようと試みた後、200の異なる方法で終わる可能性があります。

そして、その時点で、他のメーカーとは異なる問題を引き起こす特定のメーカーがいる可能性があります。仕様を更新する必要がある場合は、200種類の具体的なUSBポートの実装があり、まったく異なる方法で仕様に取り組み、更新とテストを行う必要があります。一部のメーカーは、すべてではなく、自社間で共有する事実上の標準実装（そのインターフェイスを実装するアナロジーの基本クラス）を開発する場合があります。一部のバージョンは他のバージョンより遅い場合があります。スループットは向上するものの、遅延が低下するものもあれば、その逆もあります。他のものより多くのバッテリー電力を使用するかもしれません。USBポートで動作するはずのすべてのハードウェアで動作せずに動作しないものもあります。いくつかは、原子炉を作動させるために取り付ける必要があり、それはユーザーに放射線中毒を与える傾向があります。

そして、それは私が個人的に純粋なインターフェースで見つけたものです。CPUケースに対してマザーボードのフォームファクターをモデル化するだけのように、それらが理にかなっている場合があります。実際、フォームファクターのアナロジーは、ステートレスであり、アナロジー的な「穴」と同様に機能性を欠いています。しかし、チームがすべての場合において何らかの理由で優れていると考えることは、大きな違いであることをよく考えます。

それとは反対に、ABCの方がインターフェースよりもはるかに多くのケースを解決できると思います。インターフェースが2つの選択肢である場合は、チームが非常に大きく、1つの中央標準ではなく200維持します。私が所属していた元チームでは、主に上記のメンテナンスの問題に対応するため、ABCと多重継承を許可するためにコーディング標準を緩めるためだけに実際に懸命に戦わなければなりませんでした。