C#を用いたアプリケーション開発において、インターフェース（Interface）はオブジェクト指向設計の根幹を支える極めて重要な機能です。

プログラムの柔軟性を高め、保守性の高いコードを書くためには、インターフェースの概念を正しく理解し、適切に活用することが欠かせません。

現代のC#開発では、単に「メソッドの型を定義する」という役割を超え、依存性の注入（DI）やユニットテストの容易性、さらには最新のC#バージョンで導入された静的抽象メンバーといった高度な機能まで、その活用範囲は多岐にわたります。

本記事では、インターフェースの基本概念から、抽象クラスとの決定的な違い、そして実践的な設計パターンまでを網羅的に解説します。

目次 [ close ]
  1. インターフェースの基本概念
    1. インターフェースの定義と役割
    2. 基本的な実装例
  2. インターフェースのメリットと活用する理由
    1. 1. 疎結合な設計の実現
    2. 2. 多重継承の代替
    3. 3. テスタビリティ（テストのしやすさ）の向上
  3. インターフェースと抽象クラスの違い
    1. 比較表
    2. 使い分けの基準
  4. C# 8.0以降の進化：デフォルトインターフェースメソッド
    1. デフォルト実装の書き方
  5. 実践的な活用：明示的なインターフェース実装
  6. 高度な機能：静的抽象メンバー（Static Abstract Members）
    1. 数学的な抽象化の例
  7. インターフェース設計のベストプラクティス
    1. 1. インターフェース分離の原則 (ISP)
    2. 2. 命名規則の遵守
    3. 3. 公開するAPIの最小化
  8. 実践的な活用シーン：依存性の注入（DI）
    1. DIを用いたコードの例
  9. まとめ

インターフェースの基本概念

インターフェースとは、クラスや構造体が実装すべき「振る舞いの契約」を定義するものです。

インターフェース自体は実体を持たず、どのようなメソッドやプロパティを持つべきかという「型」の定義のみを行います。

インターフェースの定義と役割

インターフェースは、interface キーワードを使用して宣言します。

慣習として、インターフェース名には先頭に 「I」 を付けるのが一般的です（例：IMovable, IDisposable）。

インターフェースを実装するクラスは、そのインターフェースで定義されているすべてのメンバーを公開（public）として実装しなければなりません。

これにより、外部のプログラムは「そのオブジェクトが具体的に何であるか」を知らなくても、「そのオブジェクトが何ができるか」を保証された状態で利用できるようになります。

基本的な実装例

まずは、最もシンプルなインターフェースの定義と実装の形を見てみましょう。

C#
using System;

// インターフェースの定義
public interface IAnimal
{
    // メソッドの定義（実装は書かない）
    void MakeSound();
    
    // プロパティの定義
    string Name { get; set; }
}

// インターフェースを実装するクラス
public class Dog : IAnimal
{
    public string Name { get; set; }

    public void MakeSound()
    {
        Console.WriteLine($"{Name} が「ワンワン！」と鳴きました。");
    }
}

public class Cat : IAnimal
{
    public string Name { get; set; }

    public void MakeSound()
    {
        Console.WriteLine($"{Name} が「ニャー」と鳴きました。");
    }
}

class Program
{
    static void Main()
    {
        // インターフェース型の変数に具象クラスを代入
        IAnimal myDog = new Dog { Name = "ポチ" };
        IAnimal myCat = new Cat { Name = "タマ" };

        myDog.MakeSound();
        myCat.MakeSound();
    }
}
実行結果
ポチ が「ワンワン！」と鳴きました。
タマ が「ニャー」と鳴きました。

この例では、IAnimal というインターフェースを介して、異なるクラス（Dog と Cat）を共通の操作方法で扱うことができています。

これがインターフェースの最大の利点の一つである多態性（ポリモーフィズム）です。

インターフェースのメリットと活用する理由

なぜ直接クラスを使わず、わざわざインターフェースを介する必要があるのでしょうか。

そこにはソフトウェア設計における重要なメリットが存在します。

1. 疎結合な設計の実現

特定のクラス（具象クラス）に依存するのではなく、インターフェース（抽象的な契約）に依存させることで、コードの結合度を下げる（疎結合にする）ことができます。

例えば、ログを出力する機能を考える際、直接「ファイルに書き込むクラス」を使うように作ってしまうと、後に「データベースに書き込むように変更したい」となった時に、呼び出し元すべてを修正しなければなりません。

インターフェースを使っていれば、実装クラスを差し替えるだけで対応が可能になります。

2. 多重継承の代替

C#のクラス継承は「単一継承」であり、一つの子クラスは一つの親クラスしか持つことができません。

しかし、インターフェースは一つのクラスに対して複数実装することが可能です。

「空を飛べる（IFlyable）」かつ「泳げる（ISwimmable）」といった、複数の性質を併せ持つオブジェクトを定義する際に、インターフェースは必須の仕組みとなります。

3. テスタビリティ（テストのしやすさ）の向上

ユニットテストを行う際、データベース接続や外部APIとの通信を行うクラスをそのまま使うと、テストの実行が困難になったり、環境に依存したりします。

インターフェースを利用していれば、テスト時だけ「本物のフリをする偽物のオブジェクト（モック）」に差し替えることができるため、ロジックのみを純粋にテストすることが可能になります。

インターフェースと抽象クラスの違い

初心者の方が最も迷いやすいのが、「インターフェースと抽象クラス（abstract class）の使い分け」です。

どちらも継承を前提とした仕組みですが、その性質は大きく異なります。

比較表

特徴インターフェース (interface)抽象クラス (abstract class)
多重継承可能（複数のインターフェースを実装できる）不可（一つのクラスのみ継承できる）
フィールド（変数）保持できない保持できる
アクセス修飾子デフォルトはpublic（C# 8.0以降は柔軟に）すべての修飾子を使用可能
実装の有無基本は持たない（C# 8.0以降はデフォルト実装可）実装を持つメソッドを含められる
コンストラクタ定義できない定義できる
意味論的な役割「～ができる（Can-do）」という能力の定義「～の一種である（Is-a）」という本質の定義

使い分けの基準

基本的には、「共通の性質や状態を共有したい場合は抽象クラス」、「異なる種類のものに共通の動作をさせたい場合はインターフェース」を選択します。

例えば、Dog と Cat はどちらも「動物」という共通の属性（血圧、心拍数など）を持つため、Animal という抽象クラスを継承するのが自然です。

一方で、Car と Dog は種類が全く違いますが、どちらも「動くもの」として扱いたい場合は IMovable インターフェースを実装するのが適切です。

C# 8.0以降の進化：デフォルトインターフェースメソッド

従来のC#では、インターフェースにメソッドを追加すると、そのインターフェースを実装しているすべてのクラスでビルドエラーが発生し、修正を余儀なくされていました。

これを解決するために導入されたのがデフォルトインターフェースメソッドです。

デフォルト実装の書き方

インターフェース内でメソッドの本体を記述することで、実装クラス側での記述を省略できるようになりました。

C#
public interface ILogger
{
    void Log(string message);

    // デフォルト実装を持つメソッド
    void LogError(string message)
    {
        Log($"[ERROR] {message}");
    }
}

public class ConsoleLogger : ILogger
{
    public void Log(string message)
    {
        Console.WriteLine(message);
    }
    // LogErrorを実装しなくてもビルドエラーにならない
}

この機能により、既存の実装クラスを壊すことなく、インターフェースに新しい機能を追加できるようになりました。

ただし、多重継承による「ダイヤモンド問題」が発生する可能性があるため、設計には注意が必要です。

実践的な活用：明示的なインターフェース実装

複数のインターフェースを実装した際、メソッド名が衝突してしまうことがあります。

その場合に役立つのが「明示的なインターフェース実装」です。

C#
using System;

interface ISaveable
{
    void Save();
}

interface IPersistable
{
    void Save();
}

class Document : ISaveable, IPersistable
{
    // 明示的な実装（publicは付けない）
    void ISaveable.Save()
    {
        Console.WriteLine("ISaveable として保存しました。");
    }

    void IPersistable.Save()
    {
        Console.WriteLine("IPersistable として保存しました。");
    }
}

class Program
{
    static void Main()
    {
        Document doc = new Document();
        
        // 直接 doc.Save() は呼べない
        // 型キャストして呼び出す
        ((ISaveable)doc).Save();
        ((IPersistable)doc).Save();
    }
}
実行結果
ISaveable として保存しました。
IPersistable として保存しました。

このように、インターフェース名.メソッド名 と記述することで、特定のインターフェース経由でアクセスされた時のみ動作するメソッドを定義できます。

これは、クラスのパブリックなAPIを汚したくない場合にも有効なテクニックです。

高度な機能：静的抽象メンバー（Static Abstract Members）

C# 11から導入された非常に強力な機能が、インターフェース内での静的抽象メンバー（static abstract members）の定義です。

これにより、インターフェースをジェネリックスと組み合わせて、静的なメソッドや演算子を抽象化できるようになりました。

数学的な抽象化の例

例えば、数値のように「足し算ができる」という性質をインターフェースで定義したい場合、従来はインスタンスメソッドにするしかありませんでしたが、静的抽象メンバーを使えば演算子自体をインターフェースに含めることができます。

C#
using System;

// 静的な抽象メンバーを持つインターフェース
public interface IAdditionOperators<TSelf> where TSelf : IAdditionOperators<TSelf>
{
    static abstract TSelf operator +(TSelf left, TSelf right);
}

public struct Point : IAdditionOperators<Point>
{
    public int X { get; set; }
    public int Y { get; set; }

    // 演算子の実装
    public static Point operator +(Point left, Point right)
    {
        return new Point { X = left.X + right.X, Y = left.Y + right.Y };
    }
}

class Program
{
    // ジェネリックメソッドで演算子を使用
    static T Add<T>(T left, T right) where T : IAdditionOperators<T>
    {
        return left + right;
    }

    static void Main()
    {
        Point p1 = new Point { X = 1, Y = 2 };
        Point p2 = new Point { X = 3, Y = 4 };
        Point result = Add(p1, p2);

        Console.WriteLine($"Result: X={result.X}, Y={result.Y}");
    }
}
実行結果
Result: X=4, Y=6

この機能は、特に数値計算ライブラリや高度なフレームワーク設計において、「型そのものに対する制約」を課すことができるため、非常に革新的です。

インターフェース設計のベストプラクティス

インターフェースは強力ですが、乱用するとコードが複雑になり、かえって保守性を損なうこともあります。

以下のベストプラクティスを意識しましょう。

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

SOLID原則の一つである「インターフェース分離の原則（Interface Segregation Principle）」は、「利用しないメソッドへの依存を強制してはならない」という考え方です。

巨大なインターフェース（Fat Interface）を作るのではなく、機能ごとに小さく分割されたインターフェースを作成しましょう。

2. 命名規則の遵守

C#ではインターフェース名に「I」を付けるのが鉄則です。

また、振る舞いを示す場合は形容詞（IDisposable, IComparable）を、役割を示す場合は名詞（IRepository, IService）を使うのが一般的です。

3. 公開するAPIの最小化

インターフェースに含めるメンバーは、外部から本当に必要なものだけに絞ってください。

実装の詳細が漏れ出してしまうと、インターフェースを変更した際の影響範囲が広がり、疎結合のメリットが失われてしまいます。

実践的な活用シーン：依存性の注入（DI）

現代のC#開発、特に ASP.NET Core や MAUI などのフレームワークにおいて、インターフェースの最も一般的な用途は「依存性の注入（Dependency Injection）」です。

DIを用いたコードの例

以下の例では、ビジネスロジック（OrderService）が特定の通知手段（メールなど）に依存せず、インターフェース（IMessageService）に依存するように設計されています。

C#
using System;

public interface IMessageService
{
    void Send(string message);
}

// メールでの通知実装
public class EmailService : IMessageService
{
    public void Send(string message)
    {
        Console.WriteLine($"メール送信: {message}");
    }
}

// SMSでの通知実装
public class SmsService : IMessageService
{
    public void Send(string message)
    {
        Console.WriteLine($"SMS送信: {message}");
    }
}

// 注文処理クラス（具体的な送信手段を知らない）
public class OrderService
{
    private readonly IMessageService _messageService;

    // コンストラクタ注入
    public OrderService(IMessageService messageService)
    {
        _messageService = messageService;
    }

    public void PlaceOrder()
    {
        // 注文処理...
        _messageService.Send("注文が完了しました。");
    }
}

class Program
{
    static void Main()
    {
        // 実行時にどちらを使うか決定できる
        IMessageService service = new EmailService();
        OrderService orderProcessor = new OrderService(service);
        
        orderProcessor.PlaceOrder();
    }
}
実行結果
メール送信: 注文が完了しました。

このように設計することで、通知手段を後から簡単に切り替えられるだけでなく、テスト時には IMessageService をモックに差し替えることで、実際にメールを送ることなく注文ロジックのテストが可能になります。

まとめ

C#のインターフェースは、単なる文法上のルールではなく、「変化に強い設計」を実現するための強力な武器です。

本記事で解説した主なポイントを振り返ります。

  • 契約の定義：実装を持たず、クラスが持つべき振る舞いを定義する。
  • 疎結合と多態性：具象クラスに依存しない設計により、コードの入れ替えや拡張が容易になる。
  • 抽象クラスとの違い：多重継承の可否や「Is-a」と「Can-do」の関係性で使い分ける。
  • 最新機能の活用：デフォルト実装による拡張性の確保や、静的抽象メンバーによる高度な抽象化。
  • DIとの親和性：現代の開発手法において、テスト容易性と保守性を高めるために必須。

インターフェースを使いこなすことは、中級以上のC#エンジニアへの第一歩です。

最初は「なぜこんなに複雑にするのか」と感じるかもしれませんが、大規模な開発や長期的なメンテナンスが必要なプロジェクトになればなるほど、その価値を実感できるようになるはずです。

まずは小さなコンポーネントの抽象化から、インターフェースを積極的に取り入れてみてください。