【C#】抽象クラスとインターフェースの違いをわかりやすく解説し設計に活かす方法

抽象クラスは共通の状態と一部実装を持つ基底クラスとして単一継承で使い、フィールドやコンストラクタを備えられます。

一方インターフェースは実装を持たず複数採用でき、クラスに能力を付与する契約として働きます。

C# 8.0以降はインターフェースでも既定実装が可能ですが、状態保持は不可のままです。

C#における抽象化レイヤーの全体像

C#のプログラミングにおいて、抽象化は非常に重要な概念です。

抽象化とは、複雑なシステムの詳細を隠し、必要な部分だけを取り出して扱いやすくすることを指します。

これにより、コードの再利用性や保守性が向上し、拡張もしやすくなります。

C#では、抽象化を実現するために主に「抽象クラス」と「インターフェース」が用いられます。

これらはどちらもオブジェクト指向プログラミングの基本的な要素であり、設計の土台となる重要な役割を担っています。

オブジェクト指向での役割

オブジェクト指向プログラミング(OOP)では、現実世界のモノや概念を「オブジェクト」としてモデル化し、それらのオブジェクトが持つ属性や振る舞いをクラスとして定義します。

抽象化はこのOOPの中核をなす考え方で、複雑なシステムをシンプルに扱うための手段です。

抽象化の役割は主に以下の3つに分けられます。

• 共通部分の抽出

複数のクラスに共通する機能や属性を抽象化し、基底クラスやインターフェースとしてまとめます。

これにより、コードの重複を減らし、変更があった場合も一箇所の修正で済むようになります。

• 実装の隠蔽

利用者は抽象化されたインターフェースや抽象クラスを通じて機能を利用し、内部の詳細な実装は隠されます。

これにより、実装の変更が外部に影響を与えにくくなり、システムの安定性が高まります。

• 多態性(ポリモーフィズム)の実現

抽象クラスやインターフェースを通じて異なるクラスのオブジェクトを同じ型として扱うことができ、柔軟なコード設計が可能になります。

これにより、拡張や機能追加が容易になります。

このように、抽象化はオブジェクト指向の設計において、コードの品質を高めるための基盤となる重要な役割を果たしています。

クラス・抽象クラス・インターフェースの位置づけ

C#の型システムにおいて、「クラス」「抽象クラス」「インターフェース」はそれぞれ異なる役割と特徴を持っています。

これらの違いを理解することは、適切な設計を行う上で欠かせません。

クラス

クラスはオブジェクトの設計図であり、実際にインスタンス化して使うことができます。

クラスは状態(フィールドやプロパティ)と振る舞い(メソッド)を持ち、具体的な処理を実装します。

通常のクラスは単一継承が可能で、他のクラスを継承して機能を拡張できます。

抽象クラス

抽象クラスは、クラスの一種ですが、直接インスタンス化できません。

抽象クラスは共通の機能や状態を持ちつつ、派生クラスに実装を強制する抽象メソッドを定義できます。

抽象クラスは部分的に実装を提供し、共通の処理をまとめる役割を持ちます。

単一継承のみ可能で、状態を保持できるため、共通のデータや初期化処理を管理したい場合に適しています。

インターフェース

インターフェースは、クラスが実装すべきメソッドやプロパティの契約を定義するもので、実装は含みません。

C# 8.0以降はデフォルト実装も可能になりましたが、フィールドは持てません。

インターフェースは多重実装が可能で、異なるクラスに共通の機能を付与したり、多様な振る舞いを持たせるために使います。

アクセス修飾子はすべてpublicで固定されており、実装の詳細はクラス側に委ねられます。

位置づけのイメージ

このように、クラスは具体的な実装を持つオブジェクトの設計図であり、抽象クラスは共通の機能や状態をまとめて部分的に実装を提供する基底クラスとして機能します。

一方、インターフェースは「何ができるか」を定義し、複数の異なるクラスに共通の機能を持たせるための契約として使われます。

これらの違いを理解し、適切に使い分けることで、C#の設計はより柔軟で拡張性の高いものになります。

抽象クラスを深掘り

定義と基本構文

abstractキーワードの意味

abstractキーワードは、クラスやメソッドに付けることで「抽象的である」ことを示します。

抽象クラスはインスタンス化できず、派生クラスで実装を補完することを前提としています。

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

抽象クラスの宣言例は以下の通りです。

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

この例ではAnimalクラスが抽象クラスであり、MakeSoundメソッドは抽象メソッドとして定義されています。

Animal自体はインスタンス化できず、MakeSoundの具体的な実装は派生クラスに任せられます。

抽象メソッドと具象メソッドの共存

抽象クラスは抽象メソッドだけでなく、具象メソッド(実装済みのメソッド)も持てます。

これにより、共通の処理を抽象クラスでまとめつつ、派生クラスで特定の処理を実装させることが可能です。

public abstract class Animal
{
    public abstract void MakeSound();
    public void Sleep()
    {
        Console.WriteLine("Sleeping...");
    }
}

この例ではSleepメソッドは具象メソッドで、すべての派生クラスで共通の動作を提供します。

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

メンバー構成の詳細

フィールドとプロパティの保持

抽象クラスはフィールドやプロパティを持つことができ、状態を管理できます。

これにより、共通のデータを抽象クラスで保持し、派生クラスで利用可能です。

public abstract class Vehicle
{
    protected int speed;
    public int Speed
    {
        get { return speed; }
        set { speed = value; }
    }
}

この例ではspeedというフィールドをprotectedで保持し、Speedプロパティでアクセスを制御しています。

派生クラスはこの状態を共有しつつ、独自の振る舞いを実装できます。

イベントとインデクサの宣言可否

抽象クラスはイベントやインデクサも宣言可能です。

イベントはデリゲートを使った通知機構で、抽象クラスで共通のイベントを定義し、派生クラスで発火させることができます。

public abstract class Button
{
    public event EventHandler Clicked;
    protected void OnClicked()
    {
        Clicked?.Invoke(this, EventArgs.Empty);
    }
}

インデクサも抽象クラスで定義でき、派生クラスで具体的なアクセス方法を実装します。

public abstract class DataCollection
{
    public abstract string this[int index] { get; set; }
}

コンストラクタと初期化ロジック

派生クラスでの呼び出し順序

抽象クラスはコンストラクタを持てます。

抽象クラスのコンストラクタは派生クラスのコンストラクタから呼び出され、初期化処理を共通化できます。

呼び出し順序は、基底クラス(抽象クラス)のコンストラクタが先に実行され、その後に派生クラスのコンストラクタが実行されます。

public abstract class Vehicle
{
    protected Vehicle()
    {
        Console.WriteLine("Vehicle constructor called.");
    }
}
public class Car : Vehicle
{
    public Car()
    {
        Console.WriteLine("Car constructor called.");
    }
}

Vehicle constructor called.
Car constructor called.

baseキーワードの活用

派生クラスのコンストラクタからbaseキーワードを使って、抽象クラスのコンストラクタに引数を渡すことも可能です。

これにより、抽象クラスの初期化に必要な情報を派生クラスから受け取れます。

public abstract class Vehicle
{
    protected int speed;
    protected Vehicle(int initialSpeed)
    {
        speed = initialSpeed;
    }
}
public class Car : Vehicle
{
    public Car(int initialSpeed) : base(initialSpeed)
    {
    }
    public void ShowSpeed()
    {
        Console.WriteLine($"Speed: {speed}");
    }
}

Speed: 100

アクセス修飾子の選択肢

protectedとprivate protected

抽象クラスのメンバーには柔軟にアクセス修飾子を設定できます。

特にprotectedは派生クラスからアクセス可能で、共通の状態やメソッドを隠蔽しつつ利用させるのに適しています。

private protectedはC# 7.2以降で使える修飾子で、同じアセンブリ内の派生クラスからのみアクセス可能にします。

これにより、外部からのアクセスを制限しつつ、同一アセンブリ内での継承を許可できます。

public abstract class BaseClass
{
    protected int protectedValue;
    private protected int privateProtectedValue;
}

内部クラスとの連携

抽象クラスの内部にprivateやprotectedな内部クラスを定義することも可能です。

これにより、抽象クラスの実装を補助するヘルパークラスを隠蔽し、外部に公開しない設計ができます。

public abstract class Container
{
    protected class Helper
    {
        public void Assist()
        {
            Console.WriteLine("Assisting...");
        }
    }
}

継承モデル

単一継承制限の影響

C#ではクラスの多重継承がサポートされていません。

抽象クラスも例外ではなく、一つのクラスしか継承できません。

これにより、設計時には継承階層を慎重に考える必要があります。

多重継承ができないため、共通機能の共有は抽象クラスの継承か、インターフェースの実装、あるいはコンポジション(委譲)で対応します。

継承階層の設計指針

抽象クラスの継承階層は深くなりすぎないように設計するのが望ましいです。

深い継承階層は理解や保守を難しくし、バグの温床になることがあります。

一般的には、抽象クラスは「is-a」関係が明確な共通機能をまとめるために使い、継承階層は3層程度に抑えることが推奨されます。

必要に応じてインターフェースやコンポジションを組み合わせると良いでしょう。

適用が有効なシナリオ

共通状態を持つドメインモデル

ドメインモデルで複数のエンティティが共通の状態や振る舞いを持つ場合、抽象クラスが適しています。

例えば、Entityという抽象クラスにIDや作成日時などの共通フィールドを持たせ、派生クラスで固有の振る舞いを実装します。

public abstract class Entity
{
    public Guid Id { get; protected set; }
    public DateTime CreatedAt { get; protected set; }
    protected Entity()
    {
        Id = Guid.NewGuid();
        CreatedAt = DateTime.UtcNow;
    }
}

このように共通の状態管理や初期化処理を抽象クラスにまとめることで、コードの重複を減らし、整合性を保てます。

テンプレートメソッドパターン利用時

テンプレートメソッドパターンは、抽象クラスで処理の骨組み(テンプレート)を定義し、派生クラスで具体的な処理を実装するデザインパターンです。

抽象クラスの具象メソッドと抽象メソッドの共存が活かされる典型的な例です。

public abstract class DataProcessor
{
    public void Process()
    {
        ReadData();
        ProcessData();
        SaveData();
    }
    protected abstract void ReadData();
    protected abstract void ProcessData();
    protected virtual void SaveData()
    {
        Console.WriteLine("Saving data...");
    }
}
public class CsvProcessor : DataProcessor
{
    protected override void ReadData()
    {
        Console.WriteLine("Reading CSV data.");
    }
    protected override void ProcessData()
    {
        Console.WriteLine("Processing CSV data.");
    }
}

Reading CSV data.
Processing CSV data.
Saving data...

このパターンでは、Processメソッドが共通の処理の流れを定義し、ReadDataやProcessDataは派生クラスで実装します。

SaveDataは具象メソッドとして共通の処理を提供しつつ、必要に応じてオーバーライドも可能です。

インターフェースを深掘り

定義と基本構文

interfaceキーワードの役割

interfaceキーワードは、クラスや構造体が実装すべきメソッドやプロパティの契約を定義するために使います。

インターフェースは実装を持たず、メンバーのシグネチャ(名前、戻り値の型、引数の型)だけを宣言します。

これにより、異なるクラス間で共通の機能を保証し、柔軟な設計を可能にします。

public interface ILogger
{
    void Log(string message);
}

この例ではILoggerインターフェースがLogメソッドの契約を定義しています。

これを実装するクラスは必ずLogメソッドを実装しなければなりません。

メンバーシグネチャの書式

インターフェース内のメンバーは、基本的に以下のようなシグネチャで定義します。

• メソッド：戻り値の型、メソッド名、引数リストのみ。実装は書かない
• プロパティ：型と名前のみ。アクセサ(get/set)の有無を指定可能です
• イベント：イベントハンドラの型と名前のみ
• インデクサ：引数の型と戻り値の型のみ

public interface IExample
{
    void DoWork(int value);
    int Result { get; }
    event EventHandler Completed;
    string this[int index] { get; set; }
}

すべてのメンバーは暗黙的にpublicであり、アクセス修飾子は指定できません。

デフォルト実装の登場

C# 8.0以前との違い

C# 8.0以前のインターフェースは、メソッドの実装を一切持てませんでした。

すべてのメソッドは抽象的で、実装はインターフェースを実装するクラスに任されていました。

しかしC# 8.0からは、インターフェース内でメソッドのデフォルト実装が可能になりました。

これにより、インターフェースの拡張が破壊的変更なしに行えるようになり、既存の実装クラスを壊さずに新機能を追加できます。

public interface ILogger
{
    void Log(string message);
    void LogWarning(string message)
    {
        Log("Warning: " + message);
    }
}

この例ではLogWarningにデフォルト実装があり、実装クラスはオーバーライドしなくても利用可能です。

既存コードへの影響

デフォルト実装の導入により、インターフェースの拡張が容易になりましたが、以下の点に注意が必要です。

• 実装クラスで同名メソッドがある場合、どちらが呼ばれるか明確にする必要があります
• デフォルト実装は状態を持てないため、複雑なロジックや状態管理には向きません
• バイナリ互換性は向上しますが、設計の複雑化を招く恐れもあるため、使いどころを見極めることが重要です

多重実装のメリット

クラス設計の柔軟性

C#ではクラスの多重継承ができませんが、複数のインターフェースを実装することは可能です。

これにより、クラスは複数の異なる機能や能力を持つことができ、設計の柔軟性が大幅に向上します。

public interface IFlyable
{
    void Fly();
}
public interface ISwimmable
{
    void Swim();
}
public class Duck : IFlyable, ISwimmable
{
    public void Fly()
    {
        Console.WriteLine("Duck is flying.");
    }
    public void Swim()
    {
        Console.WriteLine("Duck is swimming.");
    }
}

この例ではDuckクラスがIFlyableとISwimmableの両方を実装し、飛ぶ能力と泳ぐ能力を持っています。

名前衝突の解決策

複数のインターフェースに同じ名前のメソッドがある場合、名前衝突が発生します。

C#では明示的インターフェース実装を使って解決できます。

これにより、どのインターフェースのメソッドを実装しているかを明確に区別できます。

public interface IFirst
{
    void DoWork();
}
public interface ISecond
{
    void DoWork();
}
public class Worker : IFirst, ISecond
{
    void IFirst.DoWork()
    {
        Console.WriteLine("IFirst implementation");
    }
    void ISecond.DoWork()
    {
        Console.WriteLine("ISecond implementation");
    }
}

IFirst implementation
ISecond implementation

このように、呼び出し元の型によって適切なメソッドが呼ばれます。

状態を持たない設計思想

不変性とテスト容易性

インターフェースは状態を持たないため、実装クラスの状態管理は外部に委ねられます。

これにより、不変性を保ちやすくなり、テストが容易になります。

状態を持たない契約は副作用を減らし、予測可能な動作を実現します。

POCOとの親和性

インターフェースはPlain Old CLR Object(POCO)と親和性が高いです。

POCOは特定のフレームワークに依存しないシンプルなオブジェクトで、インターフェースを使うことで柔軟に振る舞いを付与できます。

これにより、ドメインモデルやDTOの設計がシンプルかつ拡張しやすくなります。

適用が有効なシナリオ

DIコンテナでの依存性注入

依存性注入(DI)では、インターフェースを使って依存関係を抽象化します。

これにより、実装の差し替えやモックの利用が容易になり、テストや保守性が向上します。

public interface IRepository
{
    void Save(object entity);
}
public class Repository : IRepository
{
    public void Save(object entity)
    {
        Console.WriteLine("Entity saved.");
    }
}
public class Service
{
    private readonly IRepository repository;
    public Service(IRepository repository)
    {
        this.repository = repository;
    }
    public void Execute()
    {
        repository.Save(new object());
    }
}

DIコンテナを使うことで、Serviceは具体的なRepositoryに依存せず、柔軟に実装を切り替えられます。

プラグインアーキテクチャ構築

プラグインアーキテクチャでは、インターフェースを使ってプラグインの契約を定義し、動的に実装を読み込むことが多いです。

これにより、拡張性が高く、機能追加が容易なシステムを構築できます。

public interface IPlugin
{
    void Run();
}
public class PluginA : IPlugin
{
    public void Run()
    {
        Console.WriteLine("PluginA running.");
    }
}

プラグインの実装はインターフェースに準拠していればよく、システム本体はプラグインの詳細を知らずに利用できます。

抽象クラスとインターフェースの比較

機能差を俯瞰する早見表

継承・実装の違い

単一継承 vs 多重実装

抽象クラスは単一継承のみ許されており、一つのクラスしか継承できません。

これにより、継承階層の設計はシンプルになりますが、複数の基底クラスから機能を継承したい場合には制約となります。

一方、インターフェースは多重実装が可能です。

クラスは複数のインターフェースを同時に実装できるため、異なる機能や能力を柔軟に組み合わせられます。

これにより、設計の自由度が高まります。

継承ツリーと依存グラフ

抽象クラスの継承はツリー構造を形成し、親クラスから子クラスへと機能や状態が受け継がれます。

依存関係は単純で追跡しやすいですが、深い継承階層は複雑さを増します。

インターフェースの実装は依存グラフのような構造になり、複数のインターフェースが一つのクラスに集約されます。

これにより、機能の分離と組み合わせが容易ですが、依存関係の管理はやや複雑になることがあります。

状態保持の可否

フィールド管理の必要性

抽象クラスはフィールドを持てるため、共通の状態を管理できます。

例えば、基底クラスでIDや設定値を保持し、派生クラスで利用する設計が可能です。

状態管理が必要なドメインモデルや共通処理の初期化に適しています。

インターフェースはフィールドを持てません。

状態を持たない契約として機能し、状態管理は実装クラスに委ねられます。

これにより、状態の不整合を防ぎ、テストや保守がしやすくなります。

readonlyフィールドの代替策

抽象クラスでreadonlyフィールドを使うことで、初期化後に変更されない状態を保証できます。

インターフェースではフィールドが持てないため、readonly相当の状態管理はできません。

代替策としては、実装クラスでreadonlyフィールドやgetのみのプロパティを使い、不変性を保つ設計が一般的です。

アクセス修飾子の幅

internalメンバーの扱い

抽象クラスはinternalやprotected internalなどのアクセス修飾子を使い、同一アセンブリ内や派生クラス限定でメンバーを公開できます。

これにより、APIの公開範囲を細かく制御可能です。

インターフェースのメンバーはすべてpublicで固定されており、アクセス修飾子を変更できません。

したがって、インターフェースは外部に公開する契約として設計されることが多いです。

API公開レベルの設計

抽象クラスは内部実装を隠しつつ、必要な部分だけを公開する設計に向いています。

ライブラリやフレームワークの内部基盤として使われることが多いです。

インターフェースはAPIの公開契約として使われ、外部からの利用を前提に設計されます。

公開範囲の制御は名前空間やアセンブリ単位で行うことが一般的です。

実装共有とコード再利用

コード重複削減手法

抽象クラスは具象メソッドを持てるため、共通の処理を一箇所にまとめてコード重複を減らせます。

派生クラスは必要な部分だけをオーバーライドし、共通処理は基底クラスに任せられます。

インターフェースは基本的に実装を持たないため、コード重複削減には向きません。

ただし、C# 8.0以降のデフォルト実装を活用すれば、ある程度の共通処理を提供できます。

拡張メソッドとの比較

インターフェースの共通処理は拡張メソッドで補うことも可能です。

拡張メソッドはインターフェースを実装するすべてのクラスで利用でき、コードの再利用に役立ちます。

ただし、拡張メソッドは仮想メソッドではないため、オーバーライドできず、動的ポリモーフィズムは実現できません。

共通処理の柔軟なカスタマイズが必要な場合は抽象クラスの方が適しています。

パフォーマンス観点

仮想呼び出しコスト

抽象クラスのメソッドは仮想メソッドとして呼び出されるため、仮想呼び出しのオーバーヘッドがあります。

インターフェースのメソッド呼び出しも仮想呼び出しに近い形で実行されますが、JITコンパイラの最適化により差はほとんどありません。

一般的なアプリケーションではパフォーマンス差は無視できるレベルですが、極端に呼び出し回数が多い場合は注意が必要です。

JIT最適化の影響

JITコンパイラは抽象クラスやインターフェースの仮想呼び出しをインライン化することがあります。

特に抽象クラスの具象メソッドはインライン化されやすく、パフォーマンスが向上します。

インターフェースのデフォルト実装もJIT最適化の恩恵を受けますが、複雑な多重実装や明示的実装が絡むと最適化が難しくなる場合があります。

C#バージョン別サポート差

C# 7.x以前

この時代のインターフェースは実装を持てず、純粋な契約のみを定義していました。

抽象クラスは具象メソッドやフィールドを持て、状態管理や共通処理の提供が可能でした。

C# 8.0以降

C# 8.0でインターフェースにデフォルト実装が導入され、インターフェースでも一部の共通処理を持てるようになりました。

ただし、フィールドは依然として持てません。

抽象クラスの機能は変わらず、状態管理やコンストラクタも利用可能です。

設計の幅が広がり、インターフェースの役割が拡張されました。

最新言語機能との連携

最新のC#バージョンでは、インターフェースのデフォルト実装がさらに強化され、静的メンバーやプライベートメソッドも定義可能になっています。

これにより、インターフェースの設計がより柔軟になりました。

抽象クラスも新しい言語機能に対応しつつ、依然として状態管理や継承の基盤として重要な役割を担っています。

設計時にはこれらの最新機能を踏まえ、適切に使い分けることが求められます。

選択基準と判断フロー

要件ドリブンの選択チャート

状態管理の有無

設計時にまず検討すべきは、クラスやコンポーネントが状態を持つ必要があるかどうかです。

状態管理が必要な場合は、抽象クラスの利用が適しています。

抽象クラスはフィールドやプロパティを持てるため、共通の状態を保持し、初期化処理もコンストラクタで行えます。

一方、状態を持たず、単に機能の契約や振る舞いの定義だけが必要な場合はインターフェースが向いています。

インターフェースは状態を持たないため、実装クラスに状態管理を任せることで柔軟性が高まります。

この判断は設計の根幹に関わるため、状態の有無を明確にしてから抽象クラスかインターフェースかを選択することが重要です。

可搬性と将来拡張

将来的に複数の異なるクラスで同じ機能を共有したい場合や、多重継承的な設計が必要な場合はインターフェースを選ぶべきです。

インターフェースは多重実装が可能で、異なるクラス階層にまたがって機能を付与できます。

また、APIの拡張性を考慮すると、C# 8.0以降のデフォルト実装を活用したインターフェースは、既存の実装を壊さずに機能追加が可能です。

これに対し、抽象クラスは単一継承の制約があり、拡張時に継承階層の見直しが必要になることがあります。

可搬性や将来の拡張を重視する場合は、インターフェースを優先的に検討すると良いでしょう。

API設計とバージョニング

破壊的変更を避けるコツ

公開APIにおいては、既存ユーザーのコードが動作し続けることが重要です。

抽象クラスやインターフェースの変更は破壊的変更になりやすいため、慎重に設計します。

抽象クラスの場合、新しい抽象メソッドを追加すると、すべての派生クラスで実装が必須となり、既存コードがコンパイルエラーになります。

これを避けるためには、新機能は具象メソッドとして追加し、既存の抽象メソッドは変更しないことが望ましいです。

インターフェースでは、C# 8.0以降のデフォルト実装を使うことで、新しいメソッドを追加しても既存の実装クラスに影響を与えずに済みます。

これにより破壊的変更を回避しやすくなります。

セマンティックバージョニング適用

APIのバージョニングにはセマンティックバージョニング(SemVer)が広く使われています。

メジャーバージョンの変更は破壊的変更を含む可能性があるため、抽象クラスやインターフェースの変更はメジャーバージョンアップに伴うべきです。

マイナーバージョンやパッチバージョンでは後方互換性を保つことが求められます。

インターフェースのデフォルト実装を活用すれば、マイナーバージョンアップで機能追加が可能です。

API設計時には、バージョニングポリシーを明確にし、抽象クラスやインターフェースの変更がどのバージョンで許容されるかを定めておくことが重要です。

公開ライブラリ開発時の指針

互換性ポリシー

公開ライブラリでは、互換性を重視した設計が求められます。

抽象クラスの変更は互換性を壊しやすいため、慎重に行う必要があります。

新しい機能は可能な限り具象メソッドや新しい抽象クラスの派生として追加し、既存の抽象クラスは安定させることが望ましいです。

インターフェースはデフォルト実装を活用し、既存の実装を壊さずに機能追加を行うことで互換性を保ちやすくなります。

ただし、複雑なデフォルト実装は保守性を下げるため、適度なバランスが必要です。

NuGet公開を見据えた設計

NuGetなどのパッケージ管理システムで公開するライブラリは、多様な環境で利用されるため、APIの安定性と拡張性が特に重要です。

抽象クラスとインターフェースの使い分けは、利用者の拡張性や依存関係に大きく影響します。

公開ライブラリでは、インターフェースを使って機能の契約を明確にし、抽象クラスは内部実装や共通処理の基盤として限定的に使う設計が一般的です。

これにより、利用者はインターフェースを通じて柔軟に拡張や差し替えが可能になります。

また、バージョニングや破壊的変更の管理を徹底し、リリースノートやドキュメントで変更点を明確に伝えることも重要です。

サンプルで学ぶ実践比較

抽象クラスによるテンプレートメソッド

共通処理と可変部の分離

テンプレートメソッドパターンは、抽象クラスで処理の骨組み(テンプレート)を定義し、派生クラスで可変部分を実装するデザインパターンです。

共通処理は抽象クラスの具象メソッドにまとめ、変化する部分は抽象メソッドとして分離します。

以下は、データ処理の流れをテンプレートメソッドで表現した例です。

using System;
public abstract class DataProcessor
{
    // テンプレートメソッド：処理の流れを定義
    public void Process()
    {
        ReadData();
        ProcessData();
        SaveData();
    }
    // 可変部分：派生クラスで実装必須
    protected abstract void ReadData();
    protected abstract void ProcessData();
    // 共通処理：具象メソッドとして提供
    protected virtual void SaveData()
    {
        Console.WriteLine("データを保存しました。");
    }
}
public class CsvProcessor : DataProcessor
{
    protected override void ReadData()
    {
        Console.WriteLine("CSVデータを読み込みます。");
    }
    protected override void ProcessData()
    {
        Console.WriteLine("CSVデータを処理します。");
    }
}
public class Program
{
    public static void Main()
    {
        DataProcessor processor = new CsvProcessor();
        processor.Process();
    }
}

CSVデータを読み込みます。
CSVデータを処理します。
データを保存しました。

この例では、Processメソッドが処理の流れを定義し、ReadDataとProcessDataは派生クラスで具体的に実装します。

SaveDataは共通処理として抽象クラスで提供し、必要に応じてオーバーライドも可能です。

テストコード概観

テンプレートメソッドパターンのテストでは、派生クラスの具体的な処理が正しく呼ばれるかを検証します。

共通処理は抽象クラスで保証されているため、主に派生クラスの動作に注目します。

using System;
using System.IO;
using System.Text;
using System.Threading.Tasks;
public class TestCsvProcessor
{
    public void TestProcess()
    {
        var output = new StringWriter();
        Console.SetOut(output);
        DataProcessor processor = new CsvProcessor();
        processor.Process();
        string expected = "CSVデータを読み込みます。\r\nCSVデータを処理します。\r\nデータを保存しました。\r\n";
        if (output.ToString() == expected)
        {
            Console.WriteLine("テスト成功");
        }
        else
        {
            Console.WriteLine("テスト失敗");
        }
    }
}
public class ProgramTest
{
    public static void Main()
    {
        var test = new TestCsvProcessor();
        test.TestProcess();
    }
}

テスト成功

このテストコードは、標準出力をキャプチャして期待される出力と比較しています。

テンプレートメソッドの流れが正しく実行されていることを確認できます。

インターフェースによる戦略パターン

実装クラスの切り替え

戦略パターンは、アルゴリズムや処理の切り替えをインターフェースで抽象化し、実装クラスを動的に切り替える設計手法です。

インターフェースを使うことで、異なる処理を簡単に差し替えられます。

以下は、支払い方法を切り替える例です。

using System;
public interface IPaymentStrategy
{
    void Pay(int amount);
}
public class CreditCardPayment : IPaymentStrategy
{
    public void Pay(int amount)
    {
        Console.WriteLine($"{amount}円をクレジットカードで支払いました。");
    }
}
public class PayPalPayment : IPaymentStrategy
{
    public void Pay(int amount)
    {
        Console.WriteLine($"{amount}円をPayPalで支払いました。");
    }
}
public class PaymentContext
{
    private IPaymentStrategy _strategy;
    public PaymentContext(IPaymentStrategy strategy)
    {
        _strategy = strategy;
    }
    public void SetStrategy(IPaymentStrategy strategy)
    {
        _strategy = strategy;
    }
    public void Pay(int amount)
    {
        _strategy.Pay(amount);
    }
}
public class Program
{
    public static void Main()
    {
        var context = new PaymentContext(new CreditCardPayment());
        context.Pay(1000);
        context.SetStrategy(new PayPalPayment());
        context.Pay(2000);
    }
}

1000円をクレジットカードで支払いました。
2000円をPayPalで支払いました。

この例では、IPaymentStrategyインターフェースを実装した複数の支払い方法を用意し、PaymentContextで動的に切り替えています。

これにより、支払い方法の追加や変更が容易になります。

DIとの統合例

依存性注入(DI)コンテナを使うと、インターフェースの実装を外部から注入でき、柔軟な設計が可能です。

以下は簡単なDIコンテナを使った例です。

using System;
public interface ILogger
{
    void Log(string message);
}
public class ConsoleLogger : ILogger
{
    public void Log(string message)
    {
        Console.WriteLine($"ログ: {message}");
    }
}
public class Service
{
    private readonly ILogger _logger;
    public Service(ILogger logger)
    {
        _logger = logger;
    }
    public void Execute()
    {
        _logger.Log("サービスを実行しました。");
    }
}
public class Program
{
    public static void Main()
    {
        // DIコンテナの代わりに手動で注入
        ILogger logger = new ConsoleLogger();
        var service = new Service(logger);
        service.Execute();
    }
}

ログ: サービスを実行しました。

この例では、ILoggerインターフェースを通じてConsoleLoggerを注入し、Serviceクラスの依存性を外部から解決しています。

DIを活用することで、テスト時にモックを差し替えたり、実装を簡単に切り替えられます。

併用パターン

抽象クラス＋インターフェースのハイブリッド

抽象クラスとインターフェースを組み合わせることで、共通処理の再利用と柔軟な契約定義を両立できます。

抽象クラスで基本的な機能や状態を持ちつつ、インターフェースで複数の能力を付与する設計が可能です。

using System;
public interface IPrintable
{
    void Print();
}
public abstract class Document
{
    public string Title { get; set; }
    public void Save()
    {
        Console.WriteLine($"{Title}を保存しました。");
    }
}
public class Report : Document, IPrintable
{
    public void Print()
    {
        Console.WriteLine($"{Title}を印刷します。");
    }
}
public class Program
{
    public static void Main()
    {
        var report = new Report { Title = "月次報告書" };
        report.Save();
        report.Print();
    }
}

月次報告書を保存しました。
月次報告書を印刷します。

この例では、Document抽象クラスで共通の保存機能を提供し、IPrintableインターフェースで印刷機能を付与しています。

Reportクラスは両方を継承・実装し、機能を組み合わせています。

制約付きジェネリックとの組み合わせ

ジェネリック型パラメータに抽象クラスやインターフェースの制約を付けることで、型安全かつ柔軟な設計が可能です。

これにより、特定の契約を満たす型だけを受け入れる汎用的なクラスやメソッドを作れます。

using System;
public interface IProcessable
{
    void Process();
}
public abstract class BaseEntity
{
    public int Id { get; set; }
}
public class Processor<T> where T : BaseEntity, IProcessable
{
    public void Execute(T item)
    {
        Console.WriteLine($"ID: {item.Id} の処理を開始します。");
        item.Process();
    }
}
public class Order : BaseEntity, IProcessable
{
    public void Process()
    {
        Console.WriteLine("注文を処理中...");
    }
}
public class Program
{
    public static void Main()
    {
        var order = new Order { Id = 123 };
        var processor = new Processor<Order>();
        processor.Execute(order);
    }
}

ID: 123 の処理を開始します。
注文を処理中...

この例では、Processor<T>クラスがTに対してBaseEntityの継承とIProcessableの実装を制約として指定しています。

これにより、ProcessorはIdプロパティとProcessメソッドを安全に利用できます。

デフォルト実装で行うリファクタリング

コード追加の手順

互換性を保つフェーズ戦略

インターフェースのデフォルト実装を活用したリファクタリングでは、既存の実装クラスに影響を与えずに機能を追加できる点が大きなメリットです。

しかし、互換性を保ちながら段階的にコードを追加するためには、計画的なフェーズ戦略が必要です。

まず、既存のインターフェースに新しいメソッドを追加する際は、必ずデフォルト実装を提供します。

これにより、既存の実装クラスは新メソッドを実装しなくてもコンパイルエラーにならず、動作も変わりません。

次に、新機能を利用するコードを段階的に導入します。

新しいメソッドを呼び出す部分は、まずはテストや限定的な環境で動作確認を行い、問題がなければ本格的に適用します。

最後に、必要に応じて実装クラスで新メソッドをオーバーライドし、最適化やカスタマイズを行います。

この段階的なアプローチにより、破壊的変更を避けつつ安全にリファクタリングを進められます。

落とし穴と回避策

実装競合の検出

デフォルト実装を複数のインターフェースで提供し、それらを同時に実装するクラスでは、同名メソッドの実装競合が発生することがあります。

この場合、どのデフォルト実装を使うかが曖昧になり、コンパイルエラーや予期せぬ動作を招く恐れがあります。

回避策としては、クラス側で明示的にどのインターフェースのメソッドを実装するかを指定する「明示的インターフェース実装」を用います。

これにより、競合を解消し、意図した実装を明確にできます。

public interface IFirst
{
    void DoWork() => Console.WriteLine("IFirstのデフォルト実装");
}
public interface ISecond
{
    void DoWork() => Console.WriteLine("ISecondのデフォルト実装");
}
public class Worker : IFirst, ISecond
{
    void IFirst.DoWork()
    {
        Console.WriteLine("WorkerのIFirst実装");
    }
    void ISecond.DoWork()
    {
        Console.WriteLine("WorkerのISecond実装");
    }
}

このように明示的に実装することで、どのメソッドが呼ばれるかを制御できます。

バージョン間の整合性

インターフェースのデフォルト実装を追加する際、バージョン間の整合性を保つことも重要です。

特に、ライブラリやフレームワークの公開APIとしてインターフェースを提供している場合、利用者の環境や実装クラスが異なるバージョンのインターフェースを参照している可能性があります。

このような場合、デフォルト実装の追加が原因で動作が変わったり、バイナリ互換性の問題が発生することがあります。

回避策としては、以下のポイントを押さえます。

• 新しいデフォルト実装は後方互換性を損なわないように設計します
• バージョンアップ時に十分なテストを行い、既存の実装が影響を受けないことを確認します
• 可能であれば、メジャーバージョンアップでの導入を検討し、利用者に変更点を明示します
• ドキュメントやリリースノートでデフォルト実装の追加を明確に伝えます

これらの対策により、バージョン間の整合性を保ちつつ、デフォルト実装を活用したリファクタリングを安全に進められます。

デザインパターン適用例

Factoryパターン

基底Productの抽象クラス化

Factoryパターンでは、生成するオブジェクトの共通の基底として抽象クラスを用いることが多いです。

抽象クラスは共通の状態や振る舞いをまとめ、派生クラスで具体的な実装を行います。

これにより、生成される製品群の一貫性を保ちつつ、拡張性を確保できます。

以下は、製品の基底クラスを抽象クラスとして定義した例です。

public abstract class Product
{
    public abstract void Use();
    public void CommonOperation()
    {
        Console.WriteLine("共通の操作を実行します。");
    }
}
public class ConcreteProductA : Product
{
    public override void Use()
    {
        Console.WriteLine("ConcreteProductAを使用します。");
    }
}
public class ConcreteProductB : Product
{
    public override void Use()
    {
        Console.WriteLine("ConcreteProductBを使用します。");
    }
}

この例では、Product抽象クラスが共通のメソッドCommonOperationを持ち、Useメソッドは派生クラスで具体的に実装します。

これにより、製品の共通機能と個別機能を分離できます。

Creatorのインターフェース化

Factoryパターンの生成者(Creator)は、生成メソッドの契約をインターフェースで定義することが多いです。

インターフェースを使うことで、複数の生成者クラスが同じ契約を実装し、生成する製品の種類を柔軟に切り替えられます。

以下は、生成者のインターフェース例です。

public interface ICreator
{
    Product FactoryMethod();
}
public class CreatorA : ICreator
{
    public Product FactoryMethod()
    {
        return new ConcreteProductA();
    }
}
public class CreatorB : ICreator
{
    public Product FactoryMethod()
    {
        return new ConcreteProductB();
    }
}

この設計により、クライアントはICreatorインターフェースを通じて製品を生成し、生成者の実装を簡単に切り替えられます。

Repositoryパターン

ドメインモデルとの親和性

Repositoryパターンは、ドメインモデルの永続化を抽象化し、データアクセスの詳細を隠蔽します。

ドメインモデルは通常、抽象クラスやインターフェースで定義され、Repositoryはこれらのモデルを扱う契約を提供します。

例えば、ドメインモデルを抽象クラスで定義し、Repositoryインターフェースで操作を規定します。

public abstract class Entity
{
    public Guid Id { get; protected set; }
}
public class Customer : Entity
{
    public string Name { get; set; }
}
public interface IRepository<T> where T : Entity
{
    void Add(T entity);
    T GetById(Guid id);
    void Remove(T entity);
}

この設計により、ドメインモデルの状態や振る舞いを保ちつつ、永続化の実装をRepositoryに委ねられます。

クエリオブジェクトの実装

Repositoryパターンでは、複雑な検索条件を扱うためにクエリオブジェクトを使うことがあります。

クエリオブジェクトは検索条件をカプセル化し、Repositoryに渡して柔軟な検索を実現します。

public class CustomerQuery
{
    public string NameContains { get; set; }
    public int? MinimumAge { get; set; }
}
public interface ICustomerRepository : IRepository<Customer>
{
    IEnumerable<Customer> Find(CustomerQuery query);
}
public class CustomerRepository : ICustomerRepository
{
    private readonly List<Customer> _customers = new List<Customer>();
    public void Add(Customer entity) => _customers.Add(entity);
    public Customer GetById(Guid id) => _customers.FirstOrDefault(c => c.Id == id);
    public void Remove(Customer entity) => _customers.Remove(entity);
    public IEnumerable<Customer> Find(CustomerQuery query)
    {
        var result = _customers.AsEnumerable();
        if (!string.IsNullOrEmpty(query.NameContains))
        {
            result = result.Where(c => c.Name.Contains(query.NameContains));
        }
        if (query.MinimumAge.HasValue)
        {
            // 年齢プロパティがあればフィルタリング(例示)
        }
        return result;
    }
}

この例では、CustomerQueryで検索条件をまとめ、Findメソッドで柔軟な検索を実現しています。

Mixin的アプローチ

部分クラスと拡張メソッド

C#では多重継承ができないため、Mixin的な振る舞いの共有には部分クラスや拡張メソッドが活用されます。

部分クラスは同じクラスを複数ファイルに分割し、機能を分担できます。

拡張メソッドは既存のクラスに新しいメソッドを追加する手段です。

// ファイル1
public partial class User
{
    public string Name { get; set; }
}
// ファイル2
public partial class User
{
    public void PrintName()
    {
        Console.WriteLine($"名前: {Name}");
    }
}
// 拡張メソッド
public static class UserExtensions
{
    public static void Greet(this User user)
    {
        Console.WriteLine($"こんにちは、{user.Name}さん！");
    }
}

このように、部分クラスで機能を分割し、拡張メソッドで振る舞いを追加することで、Mixin的な設計が可能です。

コンポジションによる振る舞い共有

コンポジションは、オブジェクトの振る舞いを別のオブジェクトに委譲する設計手法です。

Mixin的な機能共有に適しており、多重継承の代替として使われます。

public interface ILogger
{
    void Log(string message);
}
public class ConsoleLogger : ILogger
{
    public void Log(string message)
    {
        Console.WriteLine($"ログ: {message}");
    }
}
public class Service
{
    private readonly ILogger _logger;
    public Service(ILogger logger)
    {
        _logger = logger;
    }
    public void Execute()
    {
        _logger.Log("サービスを実行しました。");
    }
}

この例では、ServiceクラスがILoggerをコンポジションで持ち、ログ機能を委譲しています。

これにより、機能の再利用や差し替えが容易になります。

テストとモックの観点

モック生成フレームワーク対応

Moq

MoqはC#で最も広く使われているモック生成フレームワークの一つです。

インターフェースや仮想メソッドを持つ抽象クラスのモックを簡単に作成でき、テストコードの記述を大幅に簡素化します。

例えば、インターフェースIServiceのモックを作成し、特定のメソッド呼び出しに対して戻り値を設定する例です。

using Moq;
using System;
public interface IService
{
    int GetValue();
}
public class Program
{
    public static void Main()
    {
        var mock = new Mock<IService>();
        mock.Setup(s => s.GetValue()).Returns(42);
        IService service = mock.Object;
        Console.WriteLine(service.GetValue());
    }
}

42

Moqは抽象クラスの仮想メソッドもモック可能で、柔軟な振る舞いの設定や呼び出し回数の検証もサポートしています。

NSubstitute

NSubstituteは直感的で読みやすいAPIを特徴とするモックフレームワークです。

Moqと同様にインターフェースや抽象クラスのモックを作成でき、特に振る舞いの設定が簡潔に書ける点が魅力です。

以下はNSubstituteでのモック作成例です。

using NSubstitute;
using System;
public interface IService
{
    int GetValue();
}
public class Program
{
    public static void Main()
    {
        var service = Substitute.For<IService>();
        service.GetValue().Returns(100);
        Console.WriteLine(service.GetValue());
    }
}

100

NSubstituteは呼び出しの検証や例外のスロー設定も簡単に行え、テストコードの可読性向上に寄与します。

FakeItEasy

FakeItEasyはシンプルで使いやすいモックフレームワークで、初心者にも扱いやすい設計です。

インターフェースや抽象クラスのモックを作成し、振る舞いの設定や呼び出し検証が可能です。

以下はFakeItEasyの基本的な使用例です。

using FakeItEasy;
using System;
public interface IService
{
    int GetValue();
}
public class Program
{
    public static void Main()
    {
        var service = A.Fake<IService>();
        A.CallTo(() => service.GetValue()).Returns(7);
        Console.WriteLine(service.GetValue());
    }
}

7

FakeItEasyは直感的なAPIでテストコードの記述を簡単にし、他のフレームワークと同様に多彩な機能を備えています。

抽象クラスのFake実装

仮想メソッドのオーバーライド

抽象クラスのテストでは、仮想メソッドをオーバーライドしたFake実装を作成することが一般的です。

これにより、抽象クラスの共通処理を利用しつつ、テスト対象の振る舞いを制御できます。

以下は抽象クラスの仮想メソッドをオーバーライドしたFakeクラスの例です。

using System;
public abstract class Processor
{
    public virtual void Initialize()
    {
        Console.WriteLine("初期化処理");
    }
    public abstract void Execute();
}
public class FakeProcessor : Processor
{
    public override void Initialize()
    {
        Console.WriteLine("Fake初期化処理");
    }
    public override void Execute()
    {
        Console.WriteLine("Fake実行処理");
    }
}
public class Program
{
    public static void Main()
    {
        Processor processor = new FakeProcessor();
        processor.Initialize();
        processor.Execute();
    }
}

Fake初期化処理
Fake実行処理

このように、抽象クラスの仮想メソッドをオーバーライドしてテスト用の振る舞いを実装することで、テストの柔軟性が高まります。

インターフェースでのDIパターン

Service Locatorとの比較

Service Locatorパターンは、サービスの取得をグローバルなロケータから行う方法で、依存性の解決を集中管理します。

しかし、依存関係が隠蔽されるためテストが難しくなり、コードの可読性や保守性が低下することがあります。

一方、インターフェースを使った依存性注入(DI)は、依存関係を明示的にコンストラクタやプロパティで受け渡すため、テスト時にモックを差し替えやすく、コードの透明性が高まります。

// Service Locatorの例(非推奨)
public class ServiceLocator
{
    public static IService GetService() => new RealService();
}
public class Client
{
    public void DoWork()
    {
        var service = ServiceLocator.GetService();
        service.Perform();
    }
}

// DIパターンの例(推奨)
public interface IService
{
    void Perform();
}
public class Client
{
    private readonly IService _service;
    public Client(IService service)
    {
        _service = service;
    }
    public void DoWork()
    {
        _service.Perform();
    }
}

DIはテスト容易性や拡張性の観点で優れており、モダンなC#開発で推奨されます。

コンストラクタインジェクション

コンストラクタインジェクションは、依存オブジェクトをコンストラクタの引数として受け取るDIの代表的な手法です。

これにより、依存関係が明確になり、テスト時にモックやスタブを簡単に差し替えられます。

using System;
public interface ILogger
{
    void Log(string message);
}
public class ConsoleLogger : ILogger
{
    public void Log(string message) => Console.WriteLine(message);
}
public class Service
{
    private readonly ILogger _logger;
    public Service(ILogger logger)
    {
        _logger = logger;
    }
    public void Execute()
    {
        _logger.Log("サービスを実行しました。");
    }
}
public class Program
{
    public static void Main()
    {
        ILogger logger = new ConsoleLogger();
        var service = new Service(logger);
        service.Execute();
    }
}

サービスを実行しました。

このように、コンストラクタインジェクションを使うことで、依存関係が明示的になり、テストやメンテナンスが容易になります。

よくある誤解と注意点

抽象クラスは性能が劣る？

実行時オーバーヘッドの実測

抽象クラスは仮想メソッドを多用するため、性能が劣るという誤解があります。

しかし、実際のところ、抽象クラスの仮想メソッド呼び出しはJITコンパイラによる最適化が進んでおり、通常のメソッド呼び出しと比較しても大きな差はありません。

簡単なベンチマークを行うと、抽象クラスの仮想メソッド呼び出しとインターフェースのメソッド呼び出しはほぼ同等のオーバーヘッドであり、どちらも直接呼び出しに比べてわずかに遅い程度です。

using System;
using System.Diagnostics;
public abstract class AbstractBase
{
    public abstract void Execute();
}
public class Concrete : AbstractBase
{
    public override void Execute() { }
}
public interface IInterface
{
    void Execute();
}
public class InterfaceImpl : IInterface
{
    public void Execute() { }
}
public class Program
{
    public static void Main()
    {
        const int iterations = 100_000_000;
        var concrete = new Concrete();
        var interfaceImpl = new InterfaceImpl();
        var sw = Stopwatch.StartNew();
        for (int i = 0; i < iterations; i++)
        {
            concrete.Execute();
        }
        sw.Stop();
        Console.WriteLine($"抽象クラス呼び出し: {sw.ElapsedMilliseconds} ms");
        sw.Restart();
        for (int i = 0; i < iterations; i++)
        {
            interfaceImpl.Execute();
        }
        sw.Stop();
        Console.WriteLine($"インターフェース呼び出し: {sw.ElapsedMilliseconds} ms");
    }
}

抽象クラス呼び出し: 116 ms
インターフェース呼び出し: 119 ms

この結果からもわかるように、性能差はほとんど無視できるレベルであり、設計上の理由で抽象クラスかインターフェースを選択すべきです。

性能を気にするよりも、コードの可読性や拡張性を優先しましょう。

インターフェースにフィールドを定義できる？

静的メンバーの扱い

インターフェースは状態を持つことができず、フィールドを定義できません。

これはインターフェースの設計思想であり、「何ができるか」を定義する契約であって、状態を持つべきではないためです。

ただし、C# 8.0以降ではインターフェースに静的メンバーやデフォルト実装が導入されました。

静的メンバーはインターフェースに関連する共通の定数やヘルパーメソッドを提供するのに使えますが、インスタンスごとの状態を保持するフィールドは依然として定義できません。

public interface IConstants
{
    static int MaxValue => 100;
    static void PrintMax()
    {
        Console.WriteLine($"最大値は {MaxValue} です。");
    }
}
public class Program
{
    public static void Main()
    {
        IConstants.PrintMax();
    }
}

最大値は 100 です。

このように、静的メンバーは利用可能ですが、インターフェースのインスタンスに紐づくフィールドは定義できないことを理解しておきましょう。

デフォルト実装は万能？

保守性への影響

インターフェースのデフォルト実装は便利ですが、万能ではありません。

デフォルト実装を多用すると、インターフェースの設計が複雑化し、保守性が低下する恐れがあります。

特に、複数のインターフェースで同名のデフォルト実装が存在すると、実装クラスでの競合解決が必要になり、コードの理解や修正が難しくなります。

また、デフォルト実装内で状態を持てないため、複雑なロジックや状態管理には向きません。

設計時には、デフォルト実装はあくまで後方互換性のための補助的な手段と捉え、過度な依存は避けるべきです。

バイナリ互換性の罠

デフォルト実装を追加することで、バイナリ互換性の問題が発生することがあります。

例えば、既存の実装クラスが古いバージョンのインターフェースを参照している場合、新しいデフォルト実装が正しく反映されず、予期せぬ動作を引き起こす可能性があります。

また、デフォルト実装の変更は、既存の実装クラスに影響を与えることがあり、特にライブラリの公開APIでは慎重な管理が必要です。

バージョン管理やリリースノートで変更点を明確にし、利用者に周知することが重要です。

このような罠を避けるためには、デフォルト実装の追加や変更はメジャーバージョンアップのタイミングで行い、十分なテストと検証を行うことが推奨されます。

設計チェックリスト

導入前確認項目

ドメイン要件と合致するか

抽象クラスやインターフェースを設計に導入する際は、まずドメイン要件と合致しているかを確認します。

具体的には、以下の点を検討します。

• 共通の振る舞いや状態が存在するか

複数のクラスで共通の処理や状態を持つ場合は抽象クラスが適していることが多いです。

逆に、単に機能の契約を定義したいだけならインターフェースが適切です。

• 多重継承や複数の能力付与が必要か

複数の異なる機能を組み合わせたい場合はインターフェースの多重実装が有効です。

単一継承の抽象クラスでは対応できないケースが多いため、要件に応じて選択します。

• 状態管理や初期化処理の必要性

状態を持ち初期化が必要な場合は抽象クラスが向いています。

状態を持たず振る舞いだけを定義するならインターフェースが望ましいです。

これらの要件を明確にし、設計がドメインの実態に即しているかを確認することが重要です。

将来的な拡張計画

設計は将来的な拡張を見据えて行う必要があります。

以下のポイントを考慮します。

• 拡張のしやすさ

インターフェースはデフォルト実装を活用すれば既存実装を壊さずに機能追加が可能です。

抽象クラスは単一継承の制約があるため、拡張時に継承階層の見直しが必要になることがあります。

• 互換性の維持

公開APIの場合、破壊的変更を避けるためにインターフェースのデフォルト実装や抽象クラスの具象メソッド追加を検討します。

将来のバージョンアップでの影響を最小限に抑える設計が求められます。

• 設計の柔軟性

多様な実装が想定される場合はインターフェースを優先し、共通の基盤や状態管理が必要な場合は抽象クラスを使うなど、拡張計画に合わせて使い分けます。

将来の変更や拡張を見越した設計判断が、長期的な保守性と品質向上につながります。

コードレビュー時の観点

SOLID原則との整合性

コードレビューでは、抽象クラスやインターフェースの設計がSOLID原則に沿っているかをチェックします。

• 単一責任の原則(SRP)

抽象クラスやインターフェースは一つの責任に集中しているか。

複数の役割を持つ設計は避け、役割ごとに分割されているかを確認します。

• オープン・クローズドの原則(OCP)

既存のコードを変更せずに拡張できる設計か。

インターフェースのデフォルト実装や抽象クラスの具象メソッド追加が適切に使われているかを見ます。

• リスコフの置換原則(LSP)

派生クラスや実装クラスが基底クラスやインターフェースの契約を正しく守っているか。

振る舞いの一貫性が保たれているかを確認します。

• インターフェース分離の原則(ISP)

インターフェースが必要以上に大きくなっていないか。

クライアントが使わないメソッドを強制されていないかをチェックします。

• 依存関係逆転の原則(DIP)

高水準モジュールが低水準モジュールに依存せず、抽象に依存しているか。

依存注入が適切に使われているかを確認します。

これらの原則に沿った設計は、保守性や拡張性の高いコードを実現します。

不要な依存の排除

コードレビューでは、抽象クラスやインターフェースの依存関係が適切か、不要な依存が含まれていないかを確認します。

• 循環依存の有無

抽象クラスやインターフェース間で循環依存が発生していないか。

循環依存は設計の複雑化やビルド問題の原因となるため避けるべきです。

• 過剰な依存の排除

不要なクラスや名前空間への依存が含まれていないか。

依存は最小限に抑え、モジュールの独立性を高めることが望ましいです。

• 依存の方向性

依存関係が一方向であるか。

抽象クラスやインターフェースは上位モジュールから下位モジュールへ依存を逆転させる役割を持つため、依存の方向性を意識します。

• 依存注入の適用

依存関係がコンストラクタやプロパティで注入されているか。

直接的なインスタンス生成や静的依存は避け、テスト容易性を確保します。

これらの観点を踏まえ、不要な依存を排除し、クリーンで拡張しやすい設計を目指します。

まとめ

この記事では、C#における抽象クラスとインターフェースの違いや特徴、設計への活かし方を詳しく解説しました。

抽象クラスは状態管理や共通処理の提供に適し、単一継承の制約があります。

一方、インターフェースは多重実装が可能で、機能の契約や柔軟な拡張に向いています。

設計時にはドメイン要件や将来の拡張性を考慮し、適切に使い分けることが重要です。

また、テストやモックの活用、デフォルト実装の注意点も理解することで、堅牢で保守性の高いコード設計が実現できます。