【C#】抽象メソッドの使い方と実装例まとめ：基礎から応用までわかりやすく解説

抽象メソッドは基底クラスでシグネチャだけを宣言し、派生クラスでoverrideして具体化する機構です。

基底クラスをabstractにすると直接インスタンス化できず、実装漏れはコンパイルエラーで防げます。

共通APIと多態性を両立しながら、切替可能な実装を安全に追加できます。

抽象メソッドの基礎

抽象メソッドとは

C#における抽象メソッドは、基底クラスでメソッドの名前や引数、戻り値の型といったシグネチャだけを定義し、具体的な処理内容は記述しないメソッドです。

抽象メソッドは、派生クラスで必ずオーバーライドして実装しなければならないため、共通のインターフェースを持ちながらも、クラスごとに異なる動作を実現できます。

抽象メソッドはabstractキーワードを使って宣言し、メソッド本体は持ちません。

これにより、基底クラスは「このメソッドは必ず派生クラスで実装してください」という契約を示すことができます。

抽象メソッドを使うことで、プログラムの拡張性や保守性が高まり、異なるクラス間で共通の操作を統一的に扱うことが可能になります。

例えば、動物の鳴き声を表現する場合、MakeSoundという抽象メソッドを基底クラスに定義し、犬や猫などの派生クラスでそれぞれの鳴き声を実装するイメージです。

抽象クラスとの関係

抽象メソッドは必ず抽象クラスの中で宣言されます。

抽象クラスはabstractキーワードを使って定義し、抽象メソッドを含むことで、基底クラス自体は具体的なインスタンスを作成できない設計になります。

抽象クラスは、共通の機能やプロパティをまとめつつ、派生クラスに実装を強制したいメソッドを抽象メソッドとして宣言します。

抽象クラスは部分的に実装を持つこともできるため、共通の処理は基底クラスで実装し、派生クラスごとに異なる処理だけを抽象メソッドで定義することが多いです。

これにより、コードの重複を減らしつつ、柔軟な拡張が可能になります。

インスタンス化不可

抽象クラスはインスタンス化できません。

つまり、new演算子を使って直接抽象クラスのオブジェクトを作成することはできません。

これは、抽象クラスが未完成の設計図のようなものであり、具体的な動作を持つ派生クラスで初めて実体化できるためです。

例えば、Animalという抽象クラスがあった場合、Animal animal = new Animal();のように書くとコンパイルエラーになります。

代わりに、DogやCatなどの派生クラスをインスタンス化し、それをAnimal型の変数に代入して扱います。

これにより、抽象クラスの共通インターフェースを通じて多様な派生クラスのオブジェクトを一括管理できます。

シグネチャのみ宣言

抽象メソッドはメソッドのシグネチャだけを宣言し、メソッド本体は持ちません。

シグネチャとは、メソッド名、戻り値の型、引数の型と数、アクセス修飾子などの情報を指します。

抽象メソッドはabstractキーワードを付けて宣言し、波括弧 {} の代わりにセミコロン ; で終わります。

この特徴により、抽象メソッドは「どのようなメソッドであるか」を示すだけで、具体的な処理は派生クラスに任せることができます。

派生クラスは必ずこの抽象メソッドをoverrideキーワードを使って実装しなければなりません。

もし実装しなければ、派生クラスも抽象クラスとして扱われます。

以下は抽象メソッドの宣言例です。

public abstract class Animal
{
    // 抽象メソッドの宣言(シグネチャのみ)
    public abstract void MakeSound();
}

この例では、MakeSoundメソッドの戻り値はvoidで引数はありません。

メソッド本体はなく、派生クラスで必ず実装する必要があります。

抽象メソッドのシグネチャだけを宣言することで、基底クラスは「このメソッドは必ず実装してください」というルールを示し、派生クラスはそのルールに従って具体的な処理を記述します。

これにより、コードの一貫性と拡張性が保たれます。

抽象メソッドの宣言ルール

abstract キーワード

抽象メソッドを宣言する際は、必ずabstractキーワードをメソッドの前に付けます。

これにより、そのメソッドが抽象メソッドであることをコンパイラに示します。

abstractキーワードを付けたメソッドは、メソッド本体を持たず、セミコロンで宣言を終えます。

抽象メソッドは抽象クラス内でのみ宣言可能であり、通常のクラスやインターフェース内での使用はできません。

抽象メソッドを含むクラスは必ずabstract修飾子を付けて抽象クラスとして宣言しなければなりません。

public abstract class Shape
{
    // 抽象メソッドの宣言
    public abstract double CalculateArea();
}

この例では、CalculateAreaメソッドが抽象メソッドとして宣言されており、メソッド本体はありません。

派生クラスで必ず実装する必要があります。

アクセス修飾子の選択

抽象メソッドにはアクセス修飾子を付けることができます。

一般的にはpublicやprotectedが使われますが、privateやinternalも指定可能です。

ただし、privateの抽象メソッドは意味が薄く、ほとんど使われません。

抽象メソッドは派生クラスで必ず実装されるため、アクセス修飾子は派生クラスの実装の可視性に影響します。

例えば、protectedにすると外部からは呼び出せず、派生クラス内でのみ利用可能な設計になります。

戻り値とパラメーター

抽象メソッドは通常のメソッドと同様に戻り値の型やパラメーターを自由に指定できます。

戻り値の型はプリミティブ型、クラス型、ジェネリック型など何でも可能です。

パラメーターも複数指定でき、デフォルト値やref、outキーワードも使えます。

public abstract class Logger
{
    // メッセージをログに書き込む抽象メソッド
    public abstract void Log(string message, int level = 1);
}

この例では、Logメソッドが文字列と整数のパラメーターを受け取ります。

派生クラスはこのシグネチャに従って実装しなければなりません。

戻り値やパラメーターの型は、基底クラスと派生クラスで一致させる必要があります。

戻り値の共変性(派生クラスでより具体的な型を返す)やパラメーターの反変性はC#の抽象メソッドではサポートされていません。

static や virtual との違い

抽象メソッドはstaticメソッドと異なり、インスタンスに紐づくメソッドです。

staticメソッドはクラス自体に属し、オーバーライドや抽象化の対象になりません。

したがって、抽象メソッドにstaticキーワードを付けることはできません。

一方、virtualメソッドは基底クラスで実装を持ち、派生クラスで必要に応じてオーバーライドできます。

抽象メソッドは実装を持たず、派生クラスで必ずオーバーライドしなければなりません。

つまり、virtualは「オーバーライド可能」、abstractは「オーバーライド必須」という違いがあります。

この違いを理解して使い分けることで、柔軟で拡張性の高いクラス設計が可能になります。

抽象メソッドとインターフェース比較

共通点

抽象メソッドとインターフェースは、どちらもクラスに共通のメソッドのシグネチャを定義し、具体的な実装を派生クラスや実装クラスに任せる仕組みです。

これにより、多態性(ポリモーフィズム)を実現し、異なるクラス間で同じメソッド名を使って異なる動作を実装できます。

• 実装の強制

抽象メソッドを含む抽象クラスを継承する派生クラスや、インターフェースを実装するクラスは、定義されたメソッドを必ず実装しなければなりません。

これにより、共通の契約を守ることが保証されます。

• 多態性の提供

抽象クラスの変数やインターフェース型の変数で、異なる具体的なクラスのオブジェクトを扱い、同じメソッドを呼び出すことができます。

これにより、コードの柔軟性と拡張性が向上します。

• シグネチャの定義

どちらもメソッドの戻り値の型や引数の型、名前を定義し、実装は持ちません(インターフェースはすべてのメソッドが実装を持たないのが基本ですが、C# 8.0以降はデフォルト実装も可能です)。

相違点

抽象クラスは共通の実装を持てるため、コードの重複を減らせますが、単一継承の制約があります。

一方、インターフェースは多重実装が可能で、異なる機能を組み合わせやすい反面、実装は基本的に持ちません。

選択指針

抽象メソッドを使った抽象クラスとインターフェースのどちらを選ぶかは、設計の目的や要件によって変わります。

以下のポイントを参考にしてください。

• 共通の実装を持ちたい場合は抽象クラス

基底クラスで共通の処理やフィールドを持ち、派生クラスで一部のメソッドだけ実装を強制したい場合は抽象クラスが適しています。

例えば、共通のログ処理や状態管理を基底クラスにまとめられます。

• 多重継承や複数の契約を実現したい場合はインターフェース

C#は単一継承のため、複数の基底クラスを持てません。

複数の異なる機能をクラスに持たせたい場合は、インターフェースを複数実装する方法が有効です。

例えば、IComparableやIDisposableなどの標準インターフェースを組み合わせて使えます。

• APIの設計や外部との契約にはインターフェース

外部ライブラリやAPIの仕様として、実装の詳細を隠しつつメソッドの契約だけを示したい場合はインターフェースが適しています。

これにより、実装の差し替えやモックの作成が容易になります。

• パフォーマンスや設計の複雑さを考慮

抽象クラスは共通の実装を持つため、コードの重複を減らせますが、継承階層が深くなると複雑になります。

インターフェースはシンプルですが、実装が分散しやすいので設計の一貫性を保つ工夫が必要です。

これらを踏まえ、設計の目的や拡張性、保守性を考慮して適切な方法を選択してください。

override による実装

派生クラスでの必須実装

抽象メソッドは基底クラスでシグネチャのみが定義されており、具体的な処理は持ちません。

そのため、派生クラスでは必ずoverrideキーワードを使って抽象メソッドを実装しなければなりません。

これを怠ると、派生クラス自体も抽象クラスとして扱われ、インスタンス化できなくなります。

overrideキーワードは、基底クラスの抽象メソッドを派生クラスで具体的に実装することを明示します。

これにより、コンパイラは正しくオーバーライドされているかをチェックし、誤ったシグネチャや実装漏れを防ぎます。

以下は派生クラスでの必須実装の例です。

public abstract class Animal
{
    public abstract void MakeSound();
}
public class Dog : Animal
{
    // 抽象メソッドを必ず実装する
    public override void MakeSound()
    {
        Console.WriteLine("ワンワン");
    }
}

この例では、DogクラスがAnimalの抽象メソッドMakeSoundをoverrideして実装しています。

もしMakeSoundを実装しなければ、Dogクラスは抽象クラスとなり、インスタンス化できません。

コンパイル時チェック

C#のコンパイラは、抽象メソッドを持つ抽象クラスを継承した派生クラスに対して、抽象メソッドの実装があるかどうかを厳密にチェックします。

実装がない場合、コンパイルエラーが発生します。

例えば、以下のように抽象メソッドを実装し忘れた場合、コンパイルエラーCS0534が発生します。

public class Cat : Animal
{
    // MakeSoundを実装していないためエラーになる
}

エラーメッセージ例：

CS0534: 'Cat' does not implement inherited abstract member 'Animal.MakeSound()'

この仕組みにより、抽象メソッドの実装漏れを防ぎ、プログラムの安全性と一貫性を保てます。

基底メソッド呼び出し制御

抽象メソッドは基底クラスに実装がないため、baseキーワードを使って基底クラスの抽象メソッドを呼び出すことはできません。

つまり、派生クラスのoverrideメソッド内でbase.MakeSound()のように呼び出すことはコンパイルエラーになります。

public class Dog : Animal
{
    public override void MakeSound()
    {
        base.MakeSound(); // コンパイルエラーになる
        Console.WriteLine("ワンワン");
    }
}

エラーメッセージ例：

CS0507: 'Dog.MakeSound()': cannot change access modifiers when overriding 'abstract' inherited member 'Animal.MakeSound()'

(呼び出し自体ができないため、アクセス修飾子のエラーが出る場合もあります)

一方、抽象メソッドではなくvirtualメソッドの場合は、基底クラスに実装があるためbaseを使って基底の処理を呼び出すことが可能です。

この違いを理解して、抽象メソッドのoverride実装では基底の処理呼び出しは行わず、完全に派生クラス側で処理を記述する必要があります。

もし共通処理を基底クラスで持たせたい場合は、抽象メソッドではなくvirtualメソッドを使う設計が適しています。

実装例

動物クラスモデル

Animal 抽象クラス

動物の鳴き声を表現するために、Animalという抽象クラスを作成します。

このクラスには、鳴き声を出すための抽象メソッドMakeSoundを定義します。

MakeSoundは戻り値がなく、派生クラスで具体的な鳴き声を実装することを強制します。

public abstract class Animal
{
    // 動物の鳴き声を出す抽象メソッド
    public abstract void MakeSound();
}

このAnimalクラスはインスタンス化できず、MakeSoundメソッドの実装は派生クラスに任せられます。

Dog と Cat の具体化

Animalクラスを継承して、DogクラスとCatクラスを作成します。

両クラスはMakeSoundメソッドをoverrideして、それぞれ犬と猫の鳴き声をコンソールに出力します。

public class Dog : Animal
{
    public override void MakeSound()
    {
        Console.WriteLine("ワンワン");
    }
}
public class Cat : Animal
{
    public override void MakeSound()
    {
        Console.WriteLine("ニャー");
    }
}

これらのクラスを使って動物の鳴き声を出すプログラムの例を示します。

public class Program
{
    public static void Main()
    {
        Animal myDog = new Dog();
        myDog.MakeSound(); // 出力: ワンワン
        Animal myCat = new Cat();
        myCat.MakeSound(); // 出力: ニャー
    }
}

ワンワン
ニャー

この例では、Animal型の変数でDogやCatのインスタンスを扱い、同じMakeSoundメソッドを呼び出すことで、それぞれの動物の鳴き声を出力しています。

抽象メソッドを使うことで、異なる動物クラスに共通のインターフェースを持たせつつ、具体的な動作を柔軟に実装できます。

支払処理戦略モデル

PaymentProcessor 抽象クラス

支払処理の共通インターフェースとして、PaymentProcessorという抽象クラスを作成します。

このクラスには、支払いを実行する抽象メソッドProcessPaymentを定義します。

引数として支払金額を受け取り、戻り値は処理の成功・失敗を示すbool型とします。

public abstract class PaymentProcessor
{
    // 支払い処理を行う抽象メソッド
    public abstract bool ProcessPayment(decimal amount);
}

このクラスは支払い処理の基本的な契約を示し、具体的な支払い方法は派生クラスで実装します。

CreditCard と PayPal の具体化

PaymentProcessorを継承して、クレジットカード支払いとPayPal支払いのクラスを作成します。

両クラスはProcessPaymentメソッドをoverrideし、それぞれの支払い処理を模擬的に実装します。

public class CreditCardProcessor : PaymentProcessor
{
    public override bool ProcessPayment(decimal amount)
    {
        Console.WriteLine($"クレジットカードで{amount}円を支払いました。");
        // 実際の処理はここに実装
        return true; // 支払い成功を返す
    }
}
public class PayPalProcessor : PaymentProcessor
{
    public override bool ProcessPayment(decimal amount)
    {
        Console.WriteLine($"PayPalで{amount}円を支払いました。");
        // 実際の処理はここに実装
        return true; // 支払い成功を返す
    }
}

これらのクラスを使った支払い処理の例を示します。

public class Program
{
    public static void Main()
    {
        PaymentProcessor creditCard = new CreditCardProcessor();
        bool creditResult = creditCard.ProcessPayment(10000m);
        Console.WriteLine($"クレジットカード支払い結果: {creditResult}");
        PaymentProcessor payPal = new PayPalProcessor();
        bool payPalResult = payPal.ProcessPayment(5000m);
        Console.WriteLine($"PayPal支払い結果: {payPalResult}");
    }
}

クレジットカードで10000円を支払いました。
クレジットカード支払い結果: True
PayPalで5000円を支払いました。
PayPal支払い結果: True

この例では、PaymentProcessor型の変数で異なる支払い方法のインスタンスを扱い、同じProcessPaymentメソッドを呼び出しています。

抽象メソッドを使うことで、支払い処理の共通インターフェースを保ちながら、支払い方法ごとに異なる処理を実装できます。

メリットとデメリット

多態性と拡張性のメリット

抽象メソッドを使う最大のメリットは、多態性(ポリモーフィズム)を実現できることです。

基底クラスに抽象メソッドを定義し、派生クラスで具体的な実装を行うことで、同じメソッド名で異なる動作を実行できます。

これにより、コードの柔軟性が大幅に向上します。

例えば、AnimalクラスのMakeSoundメソッドを抽象メソッドとして定義すると、DogやCatなどの派生クラスはそれぞれ異なる鳴き声を実装できます。

呼び出し側はAnimal型の変数でこれらを扱い、同じMakeSoundメソッドを呼ぶだけで適切な動作が実行されます。

この仕組みは、以下のようなメリットをもたらします。

• コードの再利用性向上

共通のインターフェースを持つことで、汎用的な処理を基底クラスや呼び出し側でまとめられます。

• 拡張性の確保

新しい派生クラスを追加しても、既存のコードを変更せずに機能拡張が可能です。

• 保守性の向上

実装の詳細を派生クラスに隠蔽し、基底クラスや呼び出し側は抽象的な操作に集中できます。

• 設計の明確化

抽象メソッドは「必ず実装すべきメソッド」を明示するため、設計の意図が明確になります。

このように、抽象メソッドはオブジェクト指向設計の基本原則である「開放閉鎖原則(OCP)」を実現しやすくし、堅牢で拡張性の高いシステム構築に役立ちます。

過剰抽象によるデメリット

一方で、抽象メソッドを多用しすぎると過剰抽象となり、設計や実装に以下のようなデメリットが生じることがあります。

• 設計の複雑化

抽象クラスや抽象メソッドが増えすぎると、クラス階層が深くなり理解しづらくなります。

特に、抽象メソッドの数が多いと派生クラスの実装負担が増え、コードの可読性が低下します。

• 実装の煩雑化

抽象メソッドは必ず派生クラスで実装しなければならないため、簡単な処理でも多くのメソッドを実装しなければならず、開発効率が落ちる場合があります。

• 柔軟性の低下

抽象メソッドのシグネチャが固定されるため、後から変更が難しく、仕様変更に弱い設計になることがあります。

• 過剰な依存関係

抽象クラスに依存する派生クラスが増えると、変更の影響範囲が広がり、保守が難しくなることがあります。

• テストの難易度上昇

抽象メソッドを多用した設計は、モックやスタブの作成が複雑になる場合があり、単体テストの実装が難しくなることがあります。

これらのデメリットを避けるためには、抽象メソッドの導入は必要最低限にとどめ、設計のシンプルさを保つことが重要です。

場合によっては、virtualメソッドやインターフェース、デフォルト実装付きインターフェースなどの代替手段を検討することも有効です。

適切なバランスを保ちながら抽象メソッドを活用することで、設計のメリットを最大化し、デメリットを最小限に抑えられます。

デザインパターンでの活用

Template Method

Template Methodパターンは、アルゴリズムの骨組みを基底クラスで定義し、その一部の処理を抽象メソッドとして派生クラスに実装させるデザインパターンです。

抽象メソッドを使うことで、共通の処理フローを保ちつつ、具体的な処理内容を派生クラスごとにカスタマイズできます。

例えば、データの読み込みから処理、保存までの流れを基底クラスで定義し、読み込みや保存の具体的な方法を抽象メソッドとして宣言します。

派生クラスはこれらの抽象メソッドを実装し、異なるデータソースや保存先に対応できます。

public abstract class DataProcessor
{
    // テンプレートメソッド：処理の流れを定義
    public void Process()
    {
        LoadData();
        ProcessData();
        SaveData();
    }
    protected abstract void LoadData();
    protected abstract void ProcessData();
    protected abstract void SaveData();
}
public class CsvDataProcessor : DataProcessor
{
    protected override void LoadData()
    {
        Console.WriteLine("CSVファイルからデータを読み込みます。");
    }
    protected override void ProcessData()
    {
        Console.WriteLine("CSVデータを処理します。");
    }
    protected override void SaveData()
    {
        Console.WriteLine("CSVファイルにデータを保存します。");
    }
}

public class Program
{
    public static void Main()
    {
        DataProcessor processor = new CsvDataProcessor();
        processor.Process();
    }
}

CSVファイルからデータを読み込みます。
CSVデータを処理します。
CSVファイルにデータを保存します。

このように、Template Methodパターンは抽象メソッドを活用して処理の流れを固定しつつ、細部の実装を派生クラスに任せる設計に適しています。

Factory Method

Factory Methodパターンは、オブジェクトの生成をサブクラスに委譲するデザインパターンです。

基底クラスに抽象メソッドとしてファクトリーメソッドを定義し、派生クラスで具体的な生成処理を実装します。

これにより、生成するオブジェクトの種類を柔軟に切り替えられます。

例えば、ドキュメント作成アプリケーションで、異なる種類のドキュメントを生成する場合に使われます。

public abstract class DocumentCreator
{
    // ファクトリーメソッド(抽象メソッド)
    public abstract IDocument CreateDocument();
    public void NewDocument()
    {
        IDocument doc = CreateDocument();
        doc.Open();
    }
}
public interface IDocument
{
    void Open();
}
public class PdfDocument : IDocument
{
    public void Open()
    {
        Console.WriteLine("PDFドキュメントを開きます。");
    }
}
public class PdfDocumentCreator : DocumentCreator
{
    public override IDocument CreateDocument()
    {
        return new PdfDocument();
    }
}

public class Program
{
    public static void Main()
    {
        DocumentCreator creator = new PdfDocumentCreator();
        creator.NewDocument();
    }
}

PDFドキュメントを開きます。

Factory Methodパターンは、生成するオブジェクトの種類をサブクラスで決定し、基底クラスは生成の流れを管理するため、拡張性の高い設計が可能です。

Strategy

Strategyパターンは、アルゴリズムや処理の切り替えをオブジェクトとしてカプセル化し、実行時に動的に切り替えられるようにするデザインパターンです。

抽象クラスやインターフェースで共通のメソッドを定義し、具体的な戦略を派生クラスで実装します。

抽象メソッドを使うことで、異なる戦略を同じインターフェースで扱い、柔軟に切り替えられます。

public abstract class PaymentStrategy
{
    public abstract void Pay(decimal amount);
}
public class CreditCardStrategy : PaymentStrategy
{
    public override void Pay(decimal amount)
    {
        Console.WriteLine($"クレジットカードで{amount}円を支払います。");
    }
}
public class PayPalStrategy : PaymentStrategy
{
    public override void Pay(decimal amount)
    {
        Console.WriteLine($"PayPalで{amount}円を支払います。");
    }
}
public class PaymentContext
{
    private PaymentStrategy _strategy;
    public PaymentContext(PaymentStrategy strategy)
    {
        _strategy = strategy;
    }
    public void SetStrategy(PaymentStrategy strategy)
    {
        _strategy = strategy;
    }
    public void ExecutePayment(decimal amount)
    {
        _strategy.Pay(amount);
    }
}

public class Program
{
    public static void Main()
    {
        PaymentContext context = new PaymentContext(new CreditCardStrategy());
        context.ExecutePayment(10000m);
        context.SetStrategy(new PayPalStrategy());
        context.ExecutePayment(5000m);
    }
}

クレジットカードで10000円を支払います。
PayPalで5000円を支払います。

Strategyパターンは、抽象メソッドを使って異なるアルゴリズムをカプセル化し、実行時に切り替え可能にすることで、柔軟で拡張性の高い設計を実現します。

ポリモーフィズムと実行時バインディング

virtual メソッドとの比較

C#におけるポリモーフィズムは、基底クラスのメソッドを派生クラスでオーバーライドし、同じメソッド呼び出しが異なる動作を実行する仕組みです。

抽象メソッドとvirtualメソッドはどちらもこのポリモーフィズムを実現しますが、いくつかの違いがあります。

• 実装の有無

virtualメソッドは基底クラスで既に実装を持ち、必要に応じて派生クラスでオーバーライドできます。

一方、抽象メソッドは基底クラスで実装を持たず、派生クラスで必ず実装しなければなりません。

• オーバーライドの強制

抽象メソッドは派生クラスでの実装が必須ですが、virtualメソッドはオーバーライドが任意です。

派生クラスでオーバーライドしなければ、基底クラスの実装がそのまま使われます。

• クラスの性質

抽象メソッドを含むクラスは抽象クラスであり、直接インスタンス化できません。

virtualメソッドは通常のクラスでも使え、インスタンス化が可能です。

• 設計意図の違い

抽象メソッドは「このメソッドは必ず派生クラスで実装してください」という強い契約を示します。

virtualメソッドは「必要に応じてオーバーライドしてください」という柔軟な設計です。

以下の例で違いをイメージできます。

public abstract class AbstractBase
{
    public abstract void AbstractMethod(); // 実装なし、必須実装
}
public class DerivedFromAbstract : AbstractBase
{
    public override void AbstractMethod()
    {
        Console.WriteLine("抽象メソッドの実装");
    }
}
public class VirtualBase
{
    public virtual void VirtualMethod()
    {
        Console.WriteLine("基底クラスのvirtualメソッド");
    }
}
public class DerivedFromVirtual : VirtualBase
{
    public override void VirtualMethod()
    {
        Console.WriteLine("virtualメソッドのオーバーライド");
    }
}

このように、抽象メソッドは必ず派生クラスで実装しなければならず、virtualメソッドは基底クラスの実装を持ちながら必要に応じてオーバーライドできます。

呼び出しコスト

抽象メソッドやvirtualメソッドの呼び出しは、通常の非仮想メソッド呼び出しに比べてわずかにコストが高くなります。

これは、実行時バインディング(ランタイムディスパッチ)によって、呼び出すメソッドの実装が動的に決定されるためです。

• 非仮想メソッド

コンパイル時に呼び出し先が決定されるため、直接呼び出し命令が生成され、高速です。

• virtual / abstract メソッド

実行時にオブジェクトの型情報からメソッドテーブル(vtable)を参照し、適切なメソッドを呼び出します。

この間接呼び出しにより、わずかなオーバーヘッドが発生します。

ただし、現代のJITコンパイラは多くの最適化を行うため、通常のアプリケーションではこの差はほとんど気にならないレベルです。

パフォーマンスが極めて重要な場面でなければ、抽象メソッドやvirtualメソッドの使用を避ける必要はありません。

また、抽象メソッドとvirtualメソッドの呼び出しコストに大きな違いはありません。

どちらも仮想呼び出しの仕組みを使うため、実行時バインディングのオーバーヘッドはほぼ同等です。

まとめると、抽象メソッドやvirtualメソッドは動的な多態性を実現するために不可欠な機能であり、呼び出しコストはわずかですが存在します。

設計上のメリットが大きいため、パフォーマンスが問題にならない限り積極的に活用すべきです。

ジェネリクスとの組み合わせ

型制約の利用

C#のジェネリクスは、型をパラメーターとして扱うことで、柔軟かつ再利用性の高いコードを実現します。

抽象メソッドを含む抽象クラスとジェネリクスを組み合わせる際には、型パラメーターに対して型制約を設けることがよくあります。

特に、抽象クラスやインターフェースを型制約として指定することで、ジェネリック型の引数が特定の抽象クラスを継承しているか、あるいは特定のインターフェースを実装していることを保証できます。

例えば、以下のように抽象クラスAnimalを型制約に指定したジェネリッククラスを定義できます。

public abstract class Animal
{
    public abstract void MakeSound();
}
public class AnimalHandler<T> where T : Animal
{
    private T _animal;
    public AnimalHandler(T animal)
    {
        _animal = animal;
    }
    public void Handle()
    {
        _animal.MakeSound();
    }
}

この例では、AnimalHandler<T>の型パラメーターTはAnimalを継承したクラスに限定されています。

これにより、Handleメソッド内で_animal.MakeSound()を安全に呼び出せます。

もしTがAnimalを継承していなければ、コンパイルエラーとなり、型の安全性が保たれます。

型制約には以下のような種類があります。

• where T : class — 参照型に限定
• where T : struct — 値型に限定
• where T : new() — 引数なしのパブリックコンストラクターを持つ型に限定
• where T : 基底クラス名 — 特定のクラスを継承した型に限定
• where T : インターフェース名 — 特定のインターフェースを実装した型に限定

抽象メソッドを持つ抽象クラスを型制約に使うことで、ジェネリッククラスやメソッドの中で抽象メソッドを呼び出すことができ、柔軟かつ安全な設計が可能になります。

型安全性の向上

抽象メソッドを含む抽象クラスをジェネリクスの型制約に利用することで、型安全性が大幅に向上します。

型安全性とは、プログラムの実行時に型の不整合によるエラーが発生しにくいことを指します。

例えば、抽象クラスAnimalを型制約に指定しない場合、ジェネリッククラスに任意の型を渡せてしまい、MakeSoundメソッドが存在しない型に対して呼び出しを試みると実行時エラーになります。

しかし、型制約を付けることで、コンパイル時に型の整合性がチェックされ、誤った型の使用を防げます。

// 型制約なしの場合(型安全性が低い)
public class UnsafeHandler<T>
{
    private T _item;
    public UnsafeHandler(T item)
    {
        _item = item;
    }
    public void CallMakeSound()
    {
        // コンパイルエラーにはならないが、実行時に例外が発生する可能性がある
        dynamic dyn = _item;
        dyn.MakeSound();
    }
}

上記のようにdynamicを使うとコンパイル時の型チェックが無効になり、実行時にメソッドが存在しなければ例外が発生します。

一方、型制約を使うと以下のように安全に呼び出せます。

// 型制約あり(型安全)
public class SafeHandler<T> where T : Animal
{
    private T _animal;
    public SafeHandler(T animal)
    {
        _animal = animal;
    }
    public void CallMakeSound()
    {
        _animal.MakeSound(); // コンパイル時に存在が保証されている
    }
}

このように、抽象メソッドを含む抽象クラスを型制約に指定することで、ジェネリックコード内で抽象メソッドを安全に呼び出せ、実行時エラーのリスクを減らせます。

さらに、型制約を活用することで、IDEの補完機能やリファクタリング支援も向上し、開発効率が高まります。

型安全性の向上は、バグの早期発見やコードの品質向上に直結するため、抽象メソッドとジェネリクスの組み合わせは非常に有用です。

例外設計

NotImplementedException の扱い

抽象メソッドは基底クラスで実装を持たず、派生クラスで必ず実装しなければなりません。

しかし、開発の途中や一時的に実装が未完の場合、派生クラスのメソッド本体にNotImplementedExceptionを投げるコードを記述することがあります。

これは「このメソッドはまだ実装されていません」という意味を明示的に示すための例外です。

public class Dog : Animal
{
    public override void MakeSound()
    {
        throw new NotImplementedException("MakeSoundメソッドは未実装です。");
    }
}

このように書くことで、実装が未完であることが明確になり、実行時に誤って呼び出された場合に即座に例外が発生して問題を検出できます。

ただし、NotImplementedExceptionの多用は推奨されません。

特に本番環境のコードに残すと、実行時エラーの原因となりユーザー体験を損ないます。

開発段階での一時的な利用にとどめ、実装が完了したら必ず例外を除去して正常な処理を記述してください。

また、抽象メソッド自体は実装を持たないため、基底クラスでNotImplementedExceptionを投げる必要はありません。

もし基底クラスでメソッド本体を持ちつつ「未実装」を示したい場合は、抽象メソッドではなくvirtualメソッドとして実装し、未実装部分でNotImplementedExceptionを投げる設計になります。

契約的例外

抽象メソッドは「派生クラスで必ず実装すべきメソッド」という契約(契約的プログラミング)を示します。

この契約に基づき、派生クラスは基底クラスの仕様に従って正しく実装する責任があります。

例外設計においては、抽象メソッドの契約に関連する例外の扱いを明確にすることが重要です。

具体的には、以下のポイントに注意します。

• 例外の種類と意味を明確にする

抽象メソッドの仕様書やドキュメントで、どのような例外が発生しうるかを明示します。

これにより、派生クラスの実装者や利用者が例外処理を適切に行えます。

• 契約違反の例外

派生クラスが抽象メソッドの契約を守らず、不正な状態や引数で例外を投げる場合があります。

例えば、引数の検証に失敗した場合はArgumentExceptionやArgumentNullExceptionを投げることが一般的です。

• 例外の伝播とハンドリング

抽象メソッドの呼び出し元は、契約に基づく例外を適切にキャッチし、必要に応じてリカバリーやログ記録を行います。

契約的例外は予期されるものであり、設計段階で考慮しておくべきです。

• 例外の一貫性

複数の派生クラスで同じ抽象メソッドを実装する場合、例外の種類やメッセージの一貫性を保つことが望ましいです。

これにより、呼び出し側の例外処理が簡潔かつ効果的になります。

まとめると、抽象メソッドの例外設計は「契約の一部」として扱い、どのような例外が発生しうるかを明確にし、派生クラスと呼び出し側が適切に対応できるようにすることが重要です。

これにより、堅牢で予測可能なシステムを構築できます。

パフォーマンスとメモリ

オーバーヘッド計測

抽象メソッドを含む抽象クラスのメソッド呼び出しは、通常の非仮想メソッド呼び出しに比べてわずかなオーバーヘッドが発生します。

これは、抽象メソッドやvirtualメソッドが実行時バインディング(ランタイムディスパッチ)を利用しているためです。

呼び出し時にオブジェクトの型情報から適切なメソッドを動的に決定するため、間接呼び出しが発生します。

オーバーヘッドの大きさは環境やJITコンパイラの最適化によって異なりますが、一般的には数ナノ秒程度の差であり、ほとんどのアプリケーションでは無視できるレベルです。

以下のような簡単なベンチマークで、非仮想メソッドと抽象メソッドの呼び出し時間を比較できます。

public abstract class Base
{
    public abstract void AbstractMethod();
    public void NonVirtualMethod() { }
}
public class Derived : Base
{
    public override void AbstractMethod() { }
}
public class Program
{
    public static void Main()
    {
        const int iterations = 100_000_000;
        Derived obj = new Derived();
        var sw = System.Diagnostics.Stopwatch.StartNew();
        for (int i = 0; i < iterations; i++)
        {
            obj.NonVirtualMethod();
        }
        sw.Stop();
        Console.WriteLine($"Non-virtual method: {sw.ElapsedMilliseconds} ms");
        sw.Restart();
        for (int i = 0; i < iterations; i++)
        {
            obj.AbstractMethod();
        }
        sw.Stop();
        Console.WriteLine($"Abstract method: {sw.ElapsedMilliseconds} ms");
    }
}

この結果では、抽象メソッド呼び出しの方が若干遅くなることが多いですが、数十ミリ秒程度の差であり、通常の業務アプリケーションでは問題になりません。

最適化のポイント

抽象メソッドの呼び出しに伴うオーバーヘッドを最小限に抑えるためのポイントを紹介します。

• 頻繁な呼び出しを避ける

ループ内などで大量に呼び出す場合は、可能な限り呼び出し回数を減らす工夫をします。

例えば、結果をキャッシュしたり、呼び出し回数をまとめる設計にすることが有効です。

• JITコンパイラの最適化を活用する

.NETのJITコンパイラは仮想メソッドのインライン展開を行うことがあります。

特に派生クラスが確定している場合は、仮想呼び出しが非仮想呼び出しに最適化されることもあります。

最新のランタイムを利用することでパフォーマンス向上が期待できます。

• 抽象メソッドの設計を見直す

抽象メソッドの数が多すぎたり、複雑な階層構造になっている場合は、設計をシンプルにすることで呼び出しのオーバーヘッドを減らせます。

必要に応じてvirtualメソッドやインターフェースのデフォルト実装を検討するのも手です。

• 値型の利用を検討する

抽象クラスは参照型であるため、値型のようにスタック上で高速に処理できません。

パフォーマンスが重要な場合は、ジェネリクスと構造体を組み合わせるなどの工夫も検討します。

• プロファイリングツールの活用

実際のアプリケーションでパフォーマンス問題が疑われる場合は、Visual StudioのプロファイラーやJetBrains dotTraceなどのツールを使い、どのメソッド呼び出しがボトルネックになっているかを特定します。

これらのポイントを踏まえ、抽象メソッドの利用は設計の柔軟性とパフォーマンスのバランスを考慮して行うことが重要です。

多くの場合、抽象メソッドの呼び出しコストは許容範囲内であり、過度に気にする必要はありません。

コーディング規約とベストプラクティス

命名規則

抽象メソッドや抽象クラスの命名は、コードの可読性や保守性に大きく影響します。

C#の一般的な命名規則に従い、以下のポイントを押さえると良いでしょう。

• 抽象クラス名は具体的かつ意味のある名前にする

抽象クラスは共通の機能や役割を表すため、AnimalやPaymentProcessorのように、対象の概念や役割を明確に示す名前を付けます。

例：Shape, Logger, DataRepository

• 抽象メソッド名は動詞または動詞句で命名する

メソッドは動作を表すため、MakeSound(), ProcessPayment(), CalculateArea()のように動詞を使います。

これにより、メソッドの目的が直感的に理解できます。

• インターフェースとの区別

インターフェースはIで始まる名前(例：IAnimal)が一般的ですが、抽象クラスはIを付けません。

混同を避けるため、抽象クラスとインターフェースの命名規則を明確に区別しましょう。

• 派生クラスの命名

抽象クラスを継承した具体的なクラスは、抽象クラス名をベースに具体的な特徴を付け加えます。

例えば、Animalの派生クラスはDogやCatなど具体的な動物名にします。

• メソッドのオーバーライド時の命名

オーバーライドする抽象メソッドは基底クラスと同じ名前を使います。

overrideキーワードを付けて明示的にオーバーライドを示すため、命名の一貫性が保たれます。

アクセス可視性のガイドライン

抽象メソッドや抽象クラスのアクセス修飾子は、設計の意図や利用範囲に応じて適切に設定することが重要です。

以下のガイドラインを参考にしてください。

• 抽象クラスのアクセス修飾子

通常、抽象クラスはpublicまたはinternalで宣言します。

• public：ライブラリやAPIの公開部分として外部から利用される場合
• internal：同一アセンブリ内でのみ利用する場合

不要にprotectedやprivateにすることはできません。

• 抽象メソッドのアクセス修飾子

抽象メソッドは通常publicかprotectedで宣言します。

• public：外部から呼び出されることを想定したメソッド
• protected：派生クラス内でのみ利用されるメソッド。外部からは隠蔽したい場合に使います

privateの抽象メソッドは意味がなく、コンパイルエラーになります。

• 派生クラスでのアクセス修飾子の一致

抽象メソッドをオーバーライドする際は、基底クラスのアクセス修飾子と同じか、よりアクセス範囲の広い修飾子を使う必要があります。

例えば、基底クラスのprotectedメソッドをpublicにオーバーライドすることは可能ですが、その逆はできません。

• 内部実装と公開APIの分離

抽象クラスや抽象メソッドは、公開APIの一部として設計されることが多いため、アクセス修飾子を適切に設定し、内部実装を隠蔽してAPIの安定性を保つことが望ましいです。

• ドキュメントコメントの活用

アクセス修飾子に加え、XMLドキュメントコメントを使ってメソッドの利用範囲や注意点を明示すると、利用者や開発者の理解が深まります。

これらの命名規則とアクセス可視性のガイドラインを守ることで、抽象メソッドを含むクラス設計の品質が向上し、チーム開発や保守がスムーズになります。

よくあるエラーと解決策

CS0513: abstract 宣言不足

エラーコードCS0513は、「メソッドが抽象的に宣言されているが、クラスが抽象クラスとして宣言されていない」場合に発生します。

つまり、抽象メソッドを含むクラスは必ずabstractキーワードを付けて抽象クラスとして宣言しなければならないのに、それがされていないときにこのエラーが出ます。

発生例

public class Animal
{
    public abstract void MakeSound(); // エラー CS0513
}

このコードでは、Animalクラスが通常のクラスとして宣言されているのに、抽象メソッドMakeSoundを持っているためコンパイルエラーになります。

解決策

クラスにabstractキーワードを付けて抽象クラスとして宣言します。

public abstract class Animal
{
    public abstract void MakeSound();
}

これでCS0513エラーは解消されます。

抽象メソッドを持つクラスは必ず抽象クラスとして宣言することを忘れないようにしましょう。

CS0534: 未実装抽象メソッド

エラーコードCS0534は、「派生クラスが基底クラスの抽象メソッドをすべて実装していない」場合に発生します。

抽象メソッドは派生クラスで必ずoverrideして実装しなければならず、実装しないと派生クラスも抽象クラスとして扱われるため、インスタンス化できません。

発生例

public abstract class Animal
{
    public abstract void MakeSound();
}
public class Dog : Animal
{
    // MakeSoundを実装していないためエラー CS0534
}

この例では、DogクラスがMakeSoundメソッドを実装していないため、コンパイルエラーになります。

解決策

派生クラスで抽象メソッドをoverrideして実装します。

public class Dog : Animal
{
    public override void MakeSound()
    {
        Console.WriteLine("ワンワン");
    }
}

これでCS0534エラーは解消され、Dogクラスはインスタンス化可能になります。

• CS0513は抽象メソッドを持つクラスにabstract修飾子がない場合に発生します
• CS0534は派生クラスが基底クラスの抽象メソッドを実装していない場合に発生します

これらのエラーは抽象メソッドの基本的なルールに関わるもので、エラーメッセージをよく読み、クラス宣言やメソッド実装を見直すことで簡単に解決できます。

リファクタリングのアプローチ

既存コードの抽象メソッド化

既存のコードベースに抽象メソッドを導入する際は、まず共通の処理やインターフェースを抽出し、抽象クラスとしてまとめることから始めます。

これにより、コードの重複を減らし、拡張性や保守性を向上させられます。

具体的な手順は以下の通りです。

1. 共通部分の特定

複数のクラスで似たようなメソッドや処理が存在する場合、それらの共通点を洗い出します。

例えば、複数の動物クラスでMakeSoundというメソッドがあるなら、これを抽象メソッドとして抽出対象にします。

2. 抽象クラスの作成

共通のメソッドシグネチャを持つ抽象クラスを作成し、抽象メソッドとして宣言します。

基底クラスに共通の処理があれば、通常のメソッドとして実装しておきます。

3. 既存クラスの継承と実装

既存の具体的なクラスを抽象クラスから継承させ、抽象メソッドをoverrideして具体的な処理を実装します。

4. 呼び出し側の修正

呼び出し側のコードを抽象クラス型や基底クラス型に変更し、多態性を活用して柔軟に扱えるようにします。

5. テストと検証

リファクタリング後は動作確認や単体テストを行い、既存の機能が正しく動作していることを検証します。

このように段階的に抽象メソッドを導入することで、既存コードの構造を改善しつつリスクを抑えられます。

過剰抽象の削減

一方で、抽象メソッドや抽象クラスを過剰に使いすぎると、コードが複雑化し、理解や保守が難しくなることがあります。

過剰抽象は以下のような問題を引き起こします。

• クラス階層が深くなりすぎて追いにくい
• 抽象メソッドの数が多く、派生クラスの実装負担が増大
• 変更時に影響範囲が広がりやすい

過剰抽象を削減するためのアプローチは以下の通りです。

1. 不要な抽象メソッドの見直し

実装がほとんど同じメソッドや、抽象化のメリットが薄いメソッドは抽象メソッドから通常のメソッドに戻すか、共通実装として基底クラスに移します。

2. クラス階層の平坦化

深すぎる継承階層を見直し、必要に応じてインターフェースやコンポジションを活用して設計をシンプルにします。

3. 抽象クラスの統合

似た役割の抽象クラスが複数ある場合は統合を検討し、重複を減らします。

4. 設計の再評価

抽象化の目的や効果を再確認し、本当に必要な抽象化かどうかを判断します。

場合によっては、virtualメソッドやインターフェースのデフォルト実装など、他の手法に切り替えることも検討します。

5. ドキュメントとコメントの充実

抽象メソッドの役割や使い方を明確にし、チーム全体で理解を共有することで、過剰抽象の弊害を軽減します。

過剰抽象の削減は、コードの可読性と保守性を高め、開発効率の向上につながります。

リファクタリングの際は、抽象化のバランスを意識し、必要最低限の抽象メソッドに絞ることが重要です。

代替手段の検討

Default Interface Methods

C# 8.0以降で導入されたDefault Interface Methods(既定実装付きインターフェース)は、インターフェース内にメソッドの実装を持たせることができる機能です。

これにより、従来のインターフェースの「実装を持たない純粋な契約」という制約が緩和され、抽象クラスのように共通の処理をインターフェース側で提供しつつ、必要に応じて実装クラスでオーバーライドできます。

public interface ILogger
{
    void Log(string message);
    // 既定実装を持つメソッド
    void LogWarning(string message)
    {
        Log($"Warning: {message}");
    }
}
public class ConsoleLogger : ILogger
{
    public void Log(string message)
    {
        Console.WriteLine(message);
    }
}

この例では、ILoggerインターフェースにLogWarningという既定実装付きメソッドがあり、ConsoleLoggerはLogのみ実装すればよいです。

抽象クラスのように共通処理を持たせつつ、多重継承の制約を回避できるため、設計の柔軟性が向上します。

Default Interface Methodsは、抽象メソッドを使った抽象クラスの代替として検討でき、特にAPIの後方互換性を保ちながら機能拡張したい場合に有効です。

Virtual メソッド

virtualメソッドは、基底クラスで実装を持ち、派生クラスで必要に応じてオーバーライドできるメソッドです。

抽象メソッドと異なり、基底クラスにデフォルトの処理があるため、派生クラスでの実装は必須ではありません。

public class Animal
{
    public virtual void MakeSound()
    {
        Console.WriteLine("動物の鳴き声");
    }
}
public class Dog : Animal
{
    public override void MakeSound()
    {
        Console.WriteLine("ワンワン");
    }
}

この例では、AnimalクラスのMakeSoundは基底クラスで実装があり、Dogクラスでオーバーライドしています。

派生クラスでオーバーライドしなければ基底クラスの実装が使われるため、柔軟性が高いです。

抽象メソッドの代わりにvirtualメソッドを使うことで、共通の処理を基底クラスにまとめつつ、必要な部分だけ派生クラスでカスタマイズできます。

過剰な抽象化を避けたい場合や、部分的に共通処理を持たせたい場合に適しています。

パターンマッチング

C#のパターンマッチング機能を活用すると、抽象メソッドや継承を使わずに、型ごとに異なる処理を柔軟に実装できます。

特にswitch式やis演算子を使ったパターンマッチングは、条件分岐を簡潔に書けるため、シンプルなケースでの代替手段として有効です。

public abstract class Animal { }
public class Dog : Animal { }
public class Cat : Animal { }
public class Program
{
    public static void MakeSound(Animal animal)
    {
        switch (animal)
        {
            case Dog _:
                Console.WriteLine("ワンワン");
                break;
            case Cat _:
                Console.WriteLine("ニャー");
                break;
            default:
                Console.WriteLine("不明な動物");
                break;
        }
    }
    public static void Main()
    {
        Animal dog = new Dog();
        Animal cat = new Cat();
        MakeSound(dog); // ワンワン
        MakeSound(cat); // ニャー
    }
}

パターンマッチングは、継承階層を増やさずに型ごとの処理を実装できるため、小規模なケースや一時的な処理分岐に適しています。

ただし、型ごとの処理が増えるとswitch文が肥大化し、保守性が低下するため、複雑な設計には抽象メソッドやポリモーフィズムの利用が望ましいです。

これらの代替手段は、設計の目的や規模、拡張性の要件に応じて使い分けることで、より柔軟で保守しやすいコードを実現できます。

代表的ユースケース

プラグインシステム

プラグインシステムでは、アプリケーションの機能を拡張可能にするために、抽象メソッドを含む抽象クラスやインターフェースを利用してプラグインの共通契約を定義します。

これにより、異なるプラグインが同じメソッド名で独自の処理を実装でき、アプリケーションはプラグインを統一的に扱えます。

例えば、以下のようにPluginBaseという抽象クラスを定義し、Executeという抽象メソッドを持たせます。

public abstract class PluginBase
{
    public abstract void Execute();
}

各プラグインはこのクラスを継承し、Executeメソッドを実装します。

public class LoggerPlugin : PluginBase
{
    public override void Execute()
    {
        Console.WriteLine("ログを記録します。");
    }
}
public class AnalyticsPlugin : PluginBase
{
    public override void Execute()
    {
        Console.WriteLine("分析データを送信します。");
    }
}

アプリケーション側は、プラグインをPluginBase型で管理し、Executeメソッドを呼び出すだけで各プラグインの処理を実行できます。

public class Program
{
    public static void Main()
    {
        List<PluginBase> plugins = new List<PluginBase>
        {
            new LoggerPlugin(),
            new AnalyticsPlugin()
        };
        foreach (var plugin in plugins)
        {
            plugin.Execute();
        }
    }
}

ログを記録します。
分析データを送信します。

このように抽象メソッドを使うことで、プラグインの拡張性と柔軟性を高め、アプリケーションの機能追加を容易にします。

ゲーム AI

ゲーム開発において、AIの行動パターンを抽象メソッドで定義し、異なる敵キャラクターやNPCの動作を派生クラスで実装することが一般的です。

これにより、共通のインターフェースを通じて多様なAIを管理できます。

例えば、EnemyAIという抽象クラスにDecideActionという抽象メソッドを定義します。

public abstract class EnemyAI
{
    public abstract void DecideAction();
}

具体的な敵キャラクターはこのクラスを継承し、行動決定ロジックを実装します。

public class AggressiveAI : EnemyAI
{
    public override void DecideAction()
    {
        Console.WriteLine("プレイヤーに向かって攻撃します。");
    }
}
public class DefensiveAI : EnemyAI
{
    public override void DecideAction()
    {
        Console.WriteLine("距離を取りつつ防御します。");
    }
}

ゲームのメインループやAI管理システムは、EnemyAI型のリストで各AIを管理し、DecideActionを呼び出して行動を決定します。

public class Program
{
    public static void Main()
    {
        List<EnemyAI> enemies = new List<EnemyAI>
        {
            new AggressiveAI(),
            new DefensiveAI()
        };
        foreach (var enemy in enemies)
        {
            enemy.DecideAction();
        }
    }
}

プレイヤーに向かって攻撃します。
距離を取りつつ防御します。

抽象メソッドを活用することで、AIの多様な行動を統一的に扱い、拡張や調整がしやすい設計になります。

Web API ルーティング

Web APIのルーティング処理でも抽象メソッドは有効に使われます。

共通のルーティング基底クラスに抽象メソッドを定義し、各APIエンドポイントごとに派生クラスで具体的な処理を実装することで、ルーティングの拡張性と保守性を高められます。

例えば、ApiRouteという抽象クラスにHandleRequestという抽象メソッドを定義します。

public abstract class ApiRoute
{
    public abstract void HandleRequest();
}

具体的なAPIルートはこのクラスを継承し、リクエスト処理を実装します。

public class UserRoute : ApiRoute
{
    public override void HandleRequest()
    {
        Console.WriteLine("ユーザー情報を返します。");
    }
}
public class ProductRoute : ApiRoute
{
    public override void HandleRequest()
    {
        Console.WriteLine("商品情報を返します。");
    }
}

ルーティングシステムは、ApiRoute型のコレクションで各ルートを管理し、リクエストに応じて適切なHandleRequestを呼び出します。

public class Program
{
    public static void Main()
    {
        List<ApiRoute> routes = new List<ApiRoute>
        {
            new UserRoute(),
            new ProductRoute()
        };
        foreach (var route in routes)
        {
            route.HandleRequest();
        }
    }
}

ユーザー情報を返します。
商品情報を返します。

この設計により、新しいAPIエンドポイントを追加する際は、抽象クラスを継承してHandleRequestを実装するだけで済み、ルーティングの拡張が容易になります。

抽象メソッドはWeb APIの柔軟な設計に欠かせない要素です。

まとめ

この記事では、C#の抽象メソッドの基本から応用までを詳しく解説しました。

抽象メソッドの宣言ルールや派生クラスでの実装方法、抽象クラスとの関係性を理解することで、多態性を活かした柔軟な設計が可能になります。

また、デザインパターンやジェネリクスとの組み合わせ、よくあるエラーの対処法も紹介し、実践的な活用方法を学べます。

抽象メソッドを適切に使うことで、拡張性と保守性の高いコードを書く力が身につきます。