抽象メソッドまたは仮想メソッドを使用する必要がありますか？

基本クラスが純粋なインターフェイスクラスであることが望ましくないと仮定し、以下の2つの例を使用すると、抽象メソッドまたは仮想メソッドクラス定義を使用する方が適切なアプローチですか？

• 「抽象」バージョンの利点は、見た目がきれいで、派生クラスに意味のある実装を強制的に提供させることです。

• 「仮想」バージョンの利点は、他のモジュールによって簡単に引き込められ、抽象バージョンが必要とするような基本的なフレームワークを追加することなくテストに使用できることです。

要約版：

public abstract class AbstractVersion
{
    public abstract ReturnType Method1();        
    public abstract ReturnType Method2();
             .
             .
    public abstract ReturnType MethodN();

    //////////////////////////////////////////////
    // Other class implementation stuff is here
    //////////////////////////////////////////////
}

仮想バージョン：

public class VirtualVersion
{
    public virtual ReturnType Method1()
    {
        return ReturnType.NotImplemented;
    }

    public virtual ReturnType Method2()
    {
        return ReturnType.NotImplemented;
    }
             .
             .
    public virtual ReturnType MethodN()
    {
        return ReturnType.NotImplemented;
    }

    //////////////////////////////////////////////
    // Other class implementation stuff is here
    //////////////////////////////////////////////
}

私の投票は、私があなたのものを消費していた場合、抽象メソッドに対するものです。それは「早く失敗する」ことと同じです。すべてのメソッドを追加するのは宣言時に苦痛になるかもしれません（ただし、適切なリファクタリングツールはすぐにこれを行います）が、少なくとも問題が何であるかをすぐに知って修正します。6か月と12人分の変更を後でデバッグして、実装されていない例外が突然発生する理由を確認したいのです。

仮想バージョンは、バグが発生しやすく、セマンティック的に正しくありません。

Abstractは、「このメソッドはここでは実装されていません。このクラスを機能させるには実装する必要があります」と言っています。

Virtualは「デフォルトの実装を持っていますが、必要に応じて変更できます」と言っています

最終的な目的がテスト容易性である場合、通常はインターフェイスが最適なオプションです。（このクラスはaxではなくxを実行します）。ただし、これをうまく機能させるには、クラスを小さなコンポーネントに分割する必要があるかもしれません。

これは、クラスの使用法に依存します。

メソッドに合理的な「空の」実装がある場合、多くのメソッドがあり、多くの場合、それらのいくつかだけをオーバーライドしますvirtual。その後、メソッドを使用することは理にかなっています。たとえば、ExpressionVisitorこの方法で実装されます。

それ以外の場合は、abstractメソッドを使用する必要があると思います。

理想的には、実装されていないメソッドを使用すべきではありませんが、場合によってはそれが最良のアプローチです。しかし、それを行うことにした場合、そのようなメソッドはNotImplementedException特別な値を返さずにスローする必要があります。

基本クラスが実装する別のインターフェイスを定義することを再検討し、抽象的なアプローチに従うことをお勧めします。

このようなイメージングコード：

public interface IVersion
{
    ReturnType Method1();        
    ReturnType Method2();
             .
             .
    ReturnType MethodN();
}

public abstract class AbstractVersion : IVersion
{
    public abstract ReturnType Method1();        
    public abstract ReturnType Method2();
             .
             .
    public abstract ReturnType MethodN();

    //////////////////////////////////////////////
    // Other class implementation stuff is here
    //////////////////////////////////////////////
}

これにより、次の問題が解決します。

1. AbstractVersionから派生したオブジェクトを使用するすべてのコードを実装して、代わりにIVersionインターフェイスを受け取るように実装できるようになりました。つまり、ユニットテストをより簡単に行えるようになりました。

2. 製品のリリース2では、インターフェイスIVersion2を実装して、既存の顧客コードを壊すことなく追加機能を提供できます。

例えば。

public interface IVersion
{
    ReturnType Method1();        
    ReturnType Method2();
             .
             .
    ReturnType MethodN();
}

public interface IVersion2
{
    ReturnType Method2_1();
}

public abstract class AbstractVersion : IVersion, IVersion2
{
    public abstract ReturnType Method1();        
    public abstract ReturnType Method2();
             .
             .
    public abstract ReturnType MethodN();
    public abstract ReturnType Method2_1();

    //////////////////////////////////////////////
    // Other class implementation stuff is here
    //////////////////////////////////////////////
}

また、依存関係の逆転についても読む価値があります。このクラスに、効果的な単体テストを妨げるハードコーディングされた依存関係が含まれないようにするためです。

依存性注入はインターフェイスに依存しています。簡単な例を示します。クラスStudentにはCreateStudentという関数があり、インターフェイス「IReporting」を実装するパラメーターが必要です（ReportActionメソッドを使用）。学生を作成した後、具象クラスパラメータでReportActionを呼び出します。学生を作成した後に電子メールを送信するようにシステムが設定されている場合、ReportAction実装で電子メールを送信する具象クラスで送信するか、ReportAction実装でプリンタに出力を送信する別の具象クラスで送信できます。コードの再利用に最適です。