C#のインターフェースと抽象クラスの違い！オブジェクト指向の基本

オブジェクト指向プログラミングにおいて、C#で「インターフェース」と「抽象クラス」を使い分けられることは設計の良し悪しを左右します。最新の言語仕様では、インターフェースも既定の実装や静的メンバー、静的抽象メンバーなどをサポートし、抽象クラスとの差異が進化しています。本記事では、「C# インターフェース 抽象クラス 違い」をキーワードに、両者の定義、使いどころ、最新仕様での変化を具体例と比較表を使って深く解説します。

C# インターフェース 抽象クラス 違いとは何か

まず、「C# インターフェース 抽象クラス 違い」とは、プログラムでインターフェースと抽象クラスがどのような点で異なるのかを明らかにすることです。主に目的、構造、使用方法、言語の制限などが異なります。抽象クラスは部分的に実装済みの基底型として振る舞い、共通の状態や処理を持てます。一方インターフェースは契約を定義し、実装を強制しながらクラスや構造体に柔軟性を持たせる役割を果たします。

最新版の仕様では、インターフェースに既定の実装（デフォルトメソッド）、静的メソッド、静的抽象メンバーなどが追加され、抽象クラスとの境界が曖昧な部分もあります。それでもなお、状態を持つかどうか、継承の制約、コンストラクタの有無といったコアな違いは残ります。

インターフェースとは何か

インターフェースはクラスや構造体が実装しなければならないメンバー（メソッド、プロパティ、イベント、インデクサなど）の仕様を定義する契約です。実装の詳細は持たず、何をするかを宣言します。これにより、異なる型に共通の振る舞いを保証できます。最新仕様では、既定実装を提供できるため、インターフェース自身が一部の動作を持つことも可能です。

インターフェースは多重実装（複数のインターフェースを同時に実装）をサポートし、型の柔軟性を高めます。クラスや構造体は多くのインターフェースを実装でき、それぞれ異なる契約を持たせることができます。言語仕様の変化により、インターフェースに静的メソッドや静的抽象メンバーを持たせることもでき、API設計などでより強力なツールとなっています。

抽象クラスとは何か

抽象クラスはインスタンス化できないクラスであり、共通実装を持ちつつ、派生クラスで必ず実装すべき抽象メンバーを含みます。具体的なメソッド、状態（フィールド）、プロパティ、コンストラクタなどを持たせることが可能で、コードの重複を避けたり継承ツリーでの共通振る舞いを集約したりするのに適しています。

単一継承が基本であり、あるクラスは一つのクラスからしか派生できません。抽象クラスは「〜クラスである（is-a）」関係を表現し、同系のクラス間で共通機能を提供するベースとして設計されます。テンプレートメソッドパターンなど、共通の骨格を定義しつつ詳細をサブクラスに任せる設計が典型例です。

主要な違いの一覧表

いつインターフェースと抽象クラスを使い分けるか

設計フェーズで「どちらを選ぶか」は非常に重要です。ここでは具体的な判断基準とそれぞれに向く状況を解説します。最新仕様を踏まえても、抽象クラスとインターフェースは目的に応じて使い分けることが望ましいです。

抽象クラスを選ぶべき状況

以下のようなケースでは抽象クラスが適していると言えます。状態を持ち、共通の基底処理やコンストラクタが必要な場合、派生クラス間で共通の実装を提供したい場合などが典型です。たとえば、テンプレートメソッドパターンを使いたいときや、共通ロギングやバリデーションを基底で一括して行いたいときなどが該当します。

また、クラスにおけるアイデンティティ（型そのもの）を明確にしたい場合や、将来のメンテナンスで基底クラスに機能を追加したい場合も抽象クラスのほうが扱いやすい設計となります。言語仕様上からも、抽象クラスは状態管理、protected メンバー、複雑な継承構造に強い特徴があります。

インターフェースを選ぶべき状況

逆に、クラスがある機能を持つだけで良く、複数の異なる機能を組み合わせたい時、あるいは疎結合で拡張性を重視する設計の際にはインターフェースが優れます。異なるクラスが同じメソッドを提供する必要がある場合、あるいは依存性注入（DI）やモックテストを考慮する場合にインターフェースが非常に強力な手段になります。

また、API設計やライブラリ公開時には、インターフェースを契約として公開し、後から実装を変えたり追加したりする際の互換性を保つことがしやすくなります。特に既定の実装が持てるようになったことで、後方互換性を保つための設計も可能になっています。

言語仕様の最新の変化を踏まえた設計注意点

C# 8以降、インターフェースは既定の実装（default interface methods）を持てるようになりました。これにより、従来抽象クラスにしかできなかった「一部実装済み」の動作が可能になり、設計上の選択肢が増加しています。さらに C# 11 では静的抽象メンバーを備えるインターフェースも導入され、ジェネリックでの制約に活用されています。

しかし、インターフェースは依然として状態を保持できない、コンストラクタを持てない、インスタンスフィールドを持てないという制限があります。これらは抽象クラスとの差異として残っており、設計時にはこれらの制約を理解しておく必要があります。

具体例で比較：インターフェースと抽象クラスの使い方

設計の理解を深めるためには、具体的なコード例で使い方を比較することが最も効果的です。ここでは抽象クラスとインターフェースの両方で似たような目的を表現し、それぞれの利点と制約を見ていきます。

抽象クラスを使った例

例えば図形処理のライブラリを想定します。共通の振る舞いを持ちつつ派生ごとに異なる部分を実装するパターンです。抽象クラス Shape を定義し、Area や Perimeter の計算は派生クラスが行うが、描画機能や共通のプロパティは基底に実装します。

この設計により、Circle や Rectangle のような具象クラスは必要な部分だけ override すればよく、共通コードの重複を避けられます。状態（中心座標や色など）を基底に保持することで、描画処理などの実装も一箇所にまとめられます。

インターフェースを使った例

次に、支払い方法のシステムを例に取ります。クレジットカード決済、銀行振込、電子マネーなど各処理は異なりますが、共通契約として IPayment インターフェースを定義し、Pay メソッドや Refund メソッドなどを宣言します。

各クラスは IPayment を実装し、それぞれの処理内容を提供します。ここでインターフェースを使うことで、複数の支払い方法を同一のコード経路で扱え、拡張も容易です。既定実装が必要な場合は、インターフェースの default メソッドを使うこともできます。

最新仕様での折衷パターン

実践的な設計では、インターフェースを公開契約としつつ、抽象クラスで共通処理を提供するパターンがよく使われます。つまり public surface はインターフェースで、内部の共有ロジックは抽象クラスで実装するという構成です。

このパターンは、依存性注入の観点でも有効で、テストやモック化が行いやすくなります。仕様の進化に強く、後から既定実装を追加できるインターフェースや、抽象クラスへの機能追加も扱いやすい設計となります。

パフォーマンスやメンテナンスにおける違い

機能設計だけでなく、パフォーマンスや保守性にも抽象クラスとインターフェースの使い分けは影響します。多数の種類の型を組み合わせたり、大規模なライブラリを公開したりする場合にはこの点は無視できません。

実行時パフォーマンスへの影響

昔はインターフェース呼び出しのほうが仮想呼び出しを伴うためオーバーヘッドがあるとされていました。しかし現在のランタイム最適化により、その差はほとんど無いか極めて小さくなっています。多くの現場ではこのパフォーマンス差は設計の選択の主因にはなりにくいです。

むしろ、設計の明瞭さ、テストのしやすさ、将来の拡張性がパフォーマンスより重要になることが多いです。軽微な違いがあるにせよ、適切な使い分けのほうがアプリケーション全体のクオリティを左右します。

保守性と互換性への配慮

公開 API やライブラリ設計では、仕様変更時の互換性が重要です。インターフェースに新しいメンバーを追加するときには既定実装を使うことで後方互換性を保てるようになりました。抽象クラスは virtual メソッドを追加するかどうかが互換性に影響します。

また、テストコードを書く習慣のある現場ではモックを作りやすいインターフェースが重宝されます。抽象クラスは共通処理を持たせられる反面、モック対象としては過剰となることもあります。設計時には何を公開契約にするか、どこまで共通化するかを見定めることが大切です。

注意すべき誤解とよくある質問

インターフェースと抽象クラスに関しては、最初のうちは誤解されやすい点がいくつかあります。ここではその代表的なものと正しい理解を紹介します。

既定実装＝抽象クラスと同じではない

既定実装を持つインターフェースが導入されたことで、「インターフェースは全部抽象だけ」という理解は古いものになりました。しかし、インターフェースは状態を持てない、コンストラクタを持てないなど基本的制約が残ります。これらは抽象クラス固有の機能です。

そのため、「default メソッドを使えば抽象クラスが不要になる」という判断は誤りです。用途によって両者を併用する設計のほうが柔軟性と保守性に優れます。

抽象クラスは万能ではない

抽象クラスを使えば共通処理をまとめられるからといって、乱用すると継承の階層が深くなり柔軟性を失う設計になる恐れがあります。基底クラスが肥大化するとサブクラス間の意図しない依存性を生んだり、変更に弱くなる可能性があります。

また、将来的に異なる処理を追加する際に契約を変更すると抽象クラス側の派生クラスが壊れてしまうことがあります。公共 API やライブラリ作成時には設計の堅牢性を意識し、安易に抽象クラスに機能を追加することは避けるべきです。

まとめ

C#でインターフェースと抽象クラスの違いを理解することは、設計の質、拡張性、保守性に大きく影響します。インターフェースは契約を定義する手段であり、柔軟性と拡張性が高い一方、状態やコンストラクタは持てず、本質的には「何をするか」にフォーカスするものです。抽象クラスは共通動作や状態を持ち、単一継承の中で強力にコードを共通化できます。

最新の仕様ではインターフェースが既定実装や静的抽象メンバーをサポートし、両者の境界は一部でぼやけてきていますが、それぞれの強みと制約は依然として明確です。設計時には「契約か共通機能か」「将来の拡張性か状態管理か」「公開 API と内部実装の分離」を意識して選択することが、堅牢で保守性の高いコードにつながります。