【C#】ポリモーフィズムの基礎から実践まで：インターフェースと継承を使いこなす設計のコツ

2026年3月5日2026年5月5日

クラス・オブジェクト指向

C#をはじめとするオブジェクト指向プログラミング言語を習得する上で、最も強力でありながら、初心者から中級者へのステップアップにおいて最大の壁となるのがポリモーフィズム（多態性）です。

ポリモーフィズムを正しく理解し、適切に設計に組み込むことができれば、コードの再利用性は飛躍的に向上し、変更に強い柔軟なシステムを構築することが可能になります。

本記事では、C#におけるポリモーフィズムの基礎概念から、継承とインターフェースの使い分け、さらにはモダンC#での実践的な活用方法までを徹底的に解説します。

目次 [ close ]

ポリモーフィズムの本質とメリット

ポリモーフィズムとは、ギリシャ語の「多くの形態を持つ」という言葉に由来し、プログラミングにおいては「同じメソッド呼び出しが、オブジェクトの実際の型に応じて異なる振る舞いをする」性質を指します。

例えば、スマートフォン、タブレット、PCといった異なるデバイスがあるとき、私たちはそれらを「コンピューター」として共通の操作（電源を入れる、アプリを起動するなど）で扱うことができます。

しかし、内部で行われる処理は各デバイスごとに最適化されています。

このように、具体的な型を意識せずに共通のインターフェースを通じて操作できることが、ポリモーフィズムの核心です。

C#でポリモーフィズムを活用する主なメリットは以下の通りです。

コードの抽象化: 具体的な実装（How）ではなく、何をするか（What）に集中したコードが書ける。
拡張性の向上: 新しい機能を追加する際、既存のコード（呼び出し側）を修正することなく、新しいクラスを追加するだけで対応できる。
テストの容易性: 本物のオブジェクトの代わりにテスト用の「モック」を差し込むことが容易になる。

継承によるポリモーフィズム（virtualとoverride）

C#において最も伝統的なポリモーフィズムの実現方法は、クラスの継承を利用するものです。

基底クラス（親クラス）でメソッドを定義し、派生クラス（子クラス）でその動作を上書き（オーバーライド）することで、多態的な振る舞いを実現します。

virtualとoverrideの仕組み

基底クラスで、派生クラスでの書き換えを許可するメソッドには virtual キーワードを付与します。

一方、派生クラスでそのメソッドを再定義する際には override キーワードを使用します。

これにより、実行時に「インスタンスの実際の型」に基づいて適切なメソッドが呼び出されるようになります。

これを動的結合（Dynamic Binding）と呼びます。

以下に、図形を扱う簡単なプログラムの例を示します。

using System;
using System.Collections.Generic;

namespace PolymorphismDemo
{
    // 基底クラス
    public class Shape
    {
        public string Name { get; set; }

        public Shape(string name)
        {
            Name = name;
        }

        // virtualキーワードにより、派生クラスでのオーバーライドを許可する
        public virtual void Draw()
        {
            Console.WriteLine($"{Name}を描画します。");
        }
    }

    // 派生クラス：円
    public class Circle : Shape
    {
        public Circle() : base("円") { }

        // overrideキーワードにより、独自の処理を実装する
        public override void Draw()
        {
            Console.WriteLine($"{Name}をコンパスで描画します。");
        }
    }

    // 派生クラス：四角形
    public class Rectangle : Shape
    {
        public Rectangle() : base("四角形") { }

        public override void Draw()
        {
            Console.WriteLine($"{Name}を定規で描画します。");
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            // 基底クラスの型としてリストを作成
            List<Shape> shapes = new List<Shape>
            {
                new Circle(),
                new Rectangle(),
                new Shape("汎用図形")
            };

            // 各要素のDrawメソッドを呼び出す
            // 実行時にインスタンスの型に合わせて適切なDrawが呼ばれる
            foreach (var shape in shapes)
            {
                shape.Draw();
            }
        }
    }
}

実行結果

円をコンパスで描画します。
四角形を定規で描画します。
汎用図形を描画します。

この例では、List<Shape> という基底クラスのリストに、異なる派生クラスのインスタンスを格納しています。

ループの中で shape.Draw() を呼び出す際、プログラムは変数の型（Shape）ではなく、実際にメモリ上に生成されたオブジェクトの型（CircleやRectangle）を判断し、対応するメソッドを実行しています。

これがポリモーフィズムの基本動作です。

インターフェースによるポリモーフィズム

現代的なC#開発において、継承よりも頻繁に利用されるのがインターフェースです。

インターフェースは「どのようなメソッドやプロパティを持つべきか」という契約（Contract）のみを定義し、実装は一切持ちません（C# 8.0以降のデフォルト実装を除く）。

継承との違い

クラス継承が「AはBの一種である（is-a関係）」を表すのに対し、インターフェースは「AはBという振る舞いができる（can-do関係）」を表します。

C#は単一継承しか認められていないため、複数のクラスから機能を継承することはできませんが、インターフェースであれば一つのクラスが複数のインターフェースを実装することが可能です。

以下の例は、通知システムをインターフェースでモデル化したものです。

using System;
using System.Collections.Generic;

namespace InterfacePolymorphism
{
    // 通知機能の契約を定義
    public interface INotification
    {
        void Send(string message);
    }

    // メール通知の実装
    public class EmailNotification : INotification
    {
        public void Send(string message)
        {
            Console.WriteLine($"[Email] 送信中: {message}");
        }
    }

    // SMS通知の実装
    public class SmsNotification : INotification
    {
        public void Send(string message)
        {
            Console.WriteLine($"[SMS] 送信中: {message}");
        }
    }

    // 通知サービス（ポリモーフィズムを利用する側）
    public class NotificationService
    {
        private readonly List<INotification> _notifications = new List<INotification>();

        public void AddChannel(INotification notification)
        {
            _notifications.Add(notification);
        }

        public void NotifyAll(string message)
        {
            foreach (var notification in _notifications)
            {
                notification.Send(message);
            }
        }
    }

    class Program
    {
        static void Main()
        {
            var service = new NotificationService();
            
            // 具体的な実装を注入
            service.AddChannel(new EmailNotification());
            service.AddChannel(new SmsNotification());

            service.NotifyAll("システムのメンテナンスが始まります。");
        }
    }
}

実行結果

[Email] 送信中: システムのメンテナンスが始まります。
[SMS] 送信中: システムのメンテナンスが始まります。

NotificationService は、メールやSMSの具体的な仕組みを一切知りません。

ただ「INotification を実装しているオブジェクトなら、Send メソッドを呼べる」ということだけを信頼して処理を行っています。

これにより、将来的に「Slack通知」や「LINE通知」を追加したとしても、NotificationService のコードを一行も変更することなく機能を拡張できます。

抽象クラス（abstract）の使い所

「継承」と「インターフェース」の中間に位置するのが抽象クラス（abstract class）です。

抽象クラスは、それ自体をインスタンス化することはできず、派生クラスに対して特定のメソッドの実装を強制すると同時に、共通のロジックをあらかじめ提供することもできます。

使い分けの基準

特徴	インターフェース	抽象クラス
役割	振る舞いの契約（can-do）	概念的な共通基盤（is-a）
多重実装	可能	不可能（単一継承のみ）
共通ロジック	制限あり（デフォルト実装のみ）	柔軟に記述可能（フィールドも保持可）
アクセス修飾子	基本はpublic	すべての修飾子が使用可能

設計の指針としては、「迷ったらインターフェース」を選ぶのが一般的です。

インターフェースは結合度が低く、テストが容易だからです。

一方、複数の派生クラスで共有したい複雑なコードやデータがある場合には、抽象クラスを検討します。

モダンC#におけるパターンマッチングとポリモーフィズム

近年のC#（特にC# 9.0からC# 12/13にかけて）では、従来の仮想関数によるポリモーフィズムに加えて、パターンマッチングを利用した多態的な処理の記述が推奨される場面が増えています。

従来のポリモーフィズムでは、クラス側にメソッドを追加していく必要がありました。

しかし、対象となるクラス群のソースコードを変更できない場合や、データと処理を分離したい（関数型プログラミングに近いアプローチ）場合には、switch 式を用いたパターンマッチングが非常に有効です。

public record User(string Name);
public record PremiumUser(string Name, DateTime ExpiryDate) : User(Name);
public record AdminUser(string Name, string Role) : User(Name);

public class DiscountCalculator
{
    public decimal GetDiscountRate(User user) => user switch
    {
        AdminUser => 1.0m,                 // 管理者は100%オフ
        PremiumUser p when p.ExpiryDate > DateTime.Now => 0.3m, // 有効期限内のプレミアムは30%
        _ => 0.05m                         // それ以外は一律5%
    };
}

このように、型に基づいて振る舞いを分けるコードも、広義のポリモーフィズムの実現方法と言えます。

クラスの階層構造に手を加えず、外部から振る舞いを定義できるため、「既存の型に対する新しい操作」を追加する際に便利です。

実践：ポリモーフィズムを活用した設計のコツ

ポリモーフィズムを使いこなすためには、単なる構文の理解を超えた「設計の原則」を知っておく必要があります。

1. リスコフの置換原則（LSP）の遵守

ポリモーフィズムを利用する際、「基底クラス（またはインターフェース）を、その派生クラスで置き換えても、プログラムの妥当性が損なわれてはならない」という原則があります。

例えば、Bird クラスに Fly メソッドがあるとき、ペンギンクラス（Penguin）で Fly をオーバーライドして「例外を投げる」ように実装するのは、LSP違反です。

呼び出し側は「鳥なら飛べるはずだ」と期待しているため、予期せぬエラーが発生します。

このような場合は、IFlyable インターフェースを導入し、飛べる鳥だけがそれを実装するように設計を見直すべきです。

2. 依存関係逆転の原則（DIP）

上位のモジュールが下位の具体的な実装に直接依存するのではなく、両者が「抽象（インターフェース）」に依存するように設計します。

悪い例: OrderProcessor クラスが直接 SqlRepository クラスを new して使う。
良い例: OrderProcessor クラスは IOrderRepository を受け取り、具体的なストレージ（SQL, MongoDB, Memory等）には関知しない。

これにより、データベースの変更やユニットテストの実施が劇的に簡単になります。