[C#] 多重継承を許さない言語設計 — Diamond Problem と C++ の経験から考える

C++ でオブジェクト指向開発をしてきた人にとって、多重継承（Multiple Inheritance） は設計ツールボックスの定番でした。「is-a」関係を複数の基底クラスに対して宣言でき、複数の特性を持つ新しいクラスを自然にモデリングできます。

ところが C# に移行すると、クラスの多重継承はコンパイラによって明確に拒否されます。なぜ C# はこの機能を排除したのでしょうか。本記事では 多重継承そのものの解説 から始め、利点と弊害、そして C# の設計判断 までを整理します。

多重継承とは何か

多重継承とは、一つの派生クラスが 複数の基底クラス から同時に継承することです。C++ では次のように書けます。

class Printable {
public:
    virtual void Print() const { /* ... */ }
};

class Serializable {
public:
    virtual void Serialize(std::ostream& os) const { /* ... */ }
};

// Printable でもあり Serializable でもある
class Document : public Printable, public Serializable {
public:
    void Print() const override { /* ... */ }
    void Serialize(std::ostream& os) const override { /* ... */ }
};

Document は Printable でもあり（is-a）、Serializable でもある（also is-a） という関係を型システムで直接表現できます。

多重継承で得られるもの

1. 自然なモデリング

現実世界の概念は、しばしば複数の側面を持ちます。

• 水陸両用車 は LandVehicle でもあり WaterVehicle でもある
• ティーチング・アシスタント は Student でもあり Staff でもある

多重継承があれば、こうした「複数の is-a 関係」を継承階層で直接表現できます。

2. コード再利用の効率

複数の基底クラスからフィールドやメソッド実装をそのまま引き継げるため、委譲（Delegation）パターンのような間接的なコードを書く必要がありません。

class Student {
protected:
    std::string studentId_;
public:
    void Enroll(const Course& c) { /* ... */ }
};

class Staff {
protected:
    std::string employeeId_;
public:
    void SubmitTimesheet() { /* ... */ }
};

// Student の機能も Staff の機能もそのまま使える
class TeachingAssistant : public Student, public Staff {
    // Enroll() も SubmitTimesheet() もそのまま呼べる
};

C++ の設計者である Bjarne Stroustrup 自身も Artima のインタビューで、「委譲で書けばできるが、基底クラスに関数が追加されるたびにラッパーも追加しなければならず、間接的でメンテナンスの危険がある」と述べ、言語機能として多重継承を直接サポートする意義を語っています（Stroustrup は C++ の設計者であり、多重継承の擁護者側の見解です。C# がなぜ逆の判断をしたかは後述します）。

3. 型の一貫性

多重継承を使うと、TeachingAssistant のインスタンスは Student* にも Staff* にも暗黙変換できます。ポリモーフィズムが複数の階層に対して自然に働きます。

多重継承の弊害

設計段階ではすっきりしていた多重継承ですが、実装を進めると様々な問題が表面化します。

1. Diamond Problem（菱形継承問題）

最も有名な問題です。

        Person
       /      \
   Student    Staff
       \      /
  TeachingAssistant

Student と Staff がどちらも Person を継承している場合、TeachingAssistant は Person のサブオブジェクトを 2つ 持つことになります。

class Person {
public:
    std::string name_;
    virtual void Introduce() { /* ... */ }
};

class Student : public Person { /* ... */ };
class Staff   : public Person { /* ... */ };

class TeachingAssistant : public Student, public Staff {
    // name_ が2つ存在する！
    // Introduce() はどちらを呼ぶ？
};

何が問題なのか

• データの重複: name_ が Student::Person::name_ と Staff::Person::name_ の 2 箇所に存在し、一方を更新してももう一方は変わらない
• メソッドの曖昧性: ta.Introduce() がコンパイルエラー（どちらの Person::Introduce() か不明）
• 型変換の曖昧性: Person* p = &ta; もどちらの Person サブオブジェクトを指すか曖昧

C++ の対処: 仮想継承

C++ では virtual 継承を使って Person のサブオブジェクトを 1 つに畳み込めます。

class Student : virtual public Person { /* ... */ };
class Staff   : virtual public Person { /* ... */ };

class TeachingAssistant : public Student, public Staff {
    // Person のサブオブジェクトは 1 つだけ
};

しかし仮想継承はそれ自体が新たな複雑さをもたらします。

• コンストラクタの呼び出し順序 が非直感的になる（最も派生したクラスが仮想基底のコンストラクタを呼ぶ責任を持つ）
• メモリレイアウトが複雑化 し、vtable のポインタ調整が必要になる
• パフォーマンスへの影響: 仮想基底へのアクセスに間接参照が増える

2. 名前の衝突

異なる基底クラスが同名のメソッドを持つ場合、派生クラスでの呼び出しが曖昧になります。

class Printer {
public:
    void Reset() { /* プリンタをリセット */ }
};

class NetworkDevice {
public:
    void Reset() { /* ネットワーク接続をリセット */ }
};

class NetworkPrinter : public Printer, public NetworkDevice {
    // np.Reset() はコンパイルエラー
    // np.Printer::Reset() のようにスコープ解決が必要
};

関連のない 2 つの基底クラスにたまたま同名のメソッドがあるだけで、派生クラスに余計な解決コードが必要になります。

3. 脆い基底クラス問題の増幅

基底クラスに変更を加えると派生クラスが壊れる「脆い基底クラス問題（Fragile Base Class Problem）」は、単一継承でも発生します。多重継承ではこれが 複数の基底クラス分だけ増幅 されます。ある基底クラスにメンバーを追加しただけで、別の基底クラスのメンバーと名前が衝突する可能性があるのです。

4. コンストラクタ・デストラクタの順序

複数の基底クラスがある場合、構築と破棄の順序の管理が複雑になります。仮想継承が加わるとさらに予測しにくくなり、初期化の依存関係によるバグの温床となります。

5. 認知的複雑さ

多重継承を使ったクラス階層は、読む人にとって理解が困難です。「このメソッドはどの基底クラスから来たのか？」「状態はどう共有されているのか？」を追うのに、コードベース全体の継承グラフを頭に入れる必要があります。

C# はなぜ多重継承を許さないのか

公式ドキュメントの立場

Microsoft の公式ドキュメントは、C# の継承について次のように明記しています。

A derived class can have only one direct base class.

— Inheritance - C# | Microsoft Learn

そしてインターフェースについて:

A class can implement multiple interfaces even though it can derive from only a single direct base class. Interfaces are used to define specific capabilities for classes that don’t necessarily have an “is a” relationship.

C# はクラスの多重継承を 許さない 代わりに、インターフェースの複数実装 を通じて多態性を実現する設計です。

設計者 Anders Hejlsberg の設計哲学

C# の設計者である Anders Hejlsberg は、多重継承の排除について単独のインタビューや公式声明を残していません。しかし、Artima のインタビューシリーズ（2003年）で語られた C# の設計哲学から、その判断の背景を読み取ることができます。

Hejlsberg はこのインタビューで、C# の設計を 「プラグマティズム（実用主義）」 に基づくものだと繰り返し強調しています。「見かけの単純さ（simplexity）」ではなく「本質的な単純さ（true simplicity）」を追求すること、そしてバージョニング（既存コードとの互換性を保ちながらAPIを進化させること）を設計の柱に据えていたことが語られています。

この設計哲学を踏まえると、多重継承を排除した判断は以下のように理解できます:

1. 複雑さに対するコストが高すぎる: 多重継承はダイヤモンド問題やメソッドの衝突解決など、言語の実装とユーザーの理解の両面で大きな複雑さをもたらす。その複雑さに対して、得られる利便性は限定的である。Hejlsberg が批判する「simplexity」— 複雑なものを単純に見せかけているだけの状態 — に陥りやすい
2. ほとんどのケースでインターフェースが十分: 多重継承が本当に必要な場面の大多数は、「複数の契約（振る舞い）を満たしたい」というニーズであり、これはインターフェースの複数実装で解決できる
3. 言語のシンプルさとバージョニングを重視: C# は実用的な大多数のシナリオを簡潔にカバーすることを優先する設計哲学を持つ。多重継承を導入すれば、基底クラスの変更が複数の継承パスに波及し、バージョニングの問題がさらに深刻化する

この判断は C# 単独のものではなく、Java（1995年）をはじめ後発の多くの言語も同じ結論に至っています。C++ の多重継承が実際のプロジェクトで引き起こした問題を踏まえた、業界全体の「学び」と言えるでしょう。

CLR（共通言語ランタイム）の制約

C# の設計判断は言語レベルだけでなく、基盤となる CLR（Common Language Runtime） にも根ざしています。CLR の型システムはクラスの単一継承を前提に設計されており、オブジェクトのメモリレイアウトやメソッドテーブルの構造がシンプルになっています。これにより:

• GC（ガベージコレクション） がオブジェクトのレイアウトを効率的に走査できる
• JIT コンパイル でメソッド呼び出しの最適化がしやすい
• 言語間の相互運用 が容易になる（CLR 上で動く全言語が同じオブジェクトモデルを共有する）

C# での代替手段

C# では多重継承の代わりに、用途に応じた複数のアプローチが用意されています。

1. インターフェースの複数実装

最も基本的な代替手段です。「何ができるか（契約）」を定義します。

public interface IPrintable
{
    void Print();
}

public interface ISerializable
{
    void Serialize(Stream stream);
}

public class Document : IPrintable, ISerializable
{
    public void Print() { /* ... */ }
    public void Serialize(Stream stream) { /* ... */ }
}

2. デフォルトインターフェースメソッド（C# 8.0 以降）

C# 8.0 で導入された デフォルトインターフェースメソッド（Default Interface Methods） により、インターフェースにメソッドの既定実装を持たせることが可能になりました。

public interface ILogger
{
    void Log(LogLevel level, string message);

    // デフォルト実装を持つメソッド
    void Log(Exception ex) => Log(LogLevel.Error, ex.ToString());
}

これにより「インターフェースでは実装を共有できない」という従来の制約が部分的に緩和されました。ただし、インターフェースはインスタンスフィールド（状態）を持てないため、クラスの多重継承とは本質的に異なります。

C# Lead Designer の Mads Torgersen はこの機能の主な動機について、「既にリリースされたインターフェースに新しいメンバーを追加しても既存の実装を壊さない」ことだと説明しています。多重継承の代替というよりは、インターフェースの進化可能性（evolvability）を高めるための機能です。

3. コンポジション（委譲パターン）

「継承よりコンポジション（Composition over Inheritance）」は、GoF の時代から推奨されてきた設計原則です。

public class Student
{
    public string StudentId { get; }
    public void Enroll(Course course) { /* ... */ }
}

public class Staff
{
    public string EmployeeId { get; }
    public void SubmitTimesheet() { /* ... */ }
}

// 多重継承ではなくコンポジションで表現
public class TeachingAssistant
{
    private readonly Student _student = new();
    private readonly Staff _staff = new();

    public void Enroll(Course course) => _student.Enroll(course);
    public void SubmitTimesheet() => _staff.SubmitTimesheet();
}

委譲のボイラープレートが増えるデメリットはありますが、クラス間の結合度は低くなり、変更に強い設計になります。

4. 拡張メソッド

特定のインターフェースを実装する全ての型に共通のユーティリティメソッドを追加する場合に使えます。

public static class PrintableExtensions
{
    public static void PrintToConsole(this IPrintable printable)
    {
        Console.WriteLine("Printing...");
        printable.Print();
    }
}

手法の選択指針

C++ 経験者の視点から

C++ で多重継承を使った設計は、確かに設計段階では美しく見えます。「TeachingAssistant は Student であり Staff でもある」— これは論理的に正しいモデリングです。

しかし実装を進めると、前述したような問題に直面します。仮想継承の導入、コンストラクタの連鎖の管理、予期しない名前衝突の解決。設計段階の「すっきり感」は、実装の泥沼に変わり得ます。

C# の「単一継承＋複数インターフェース」という制約は、一見すると表現力の低下に感じるかもしれません。しかし実際には、設計段階で “is-a” の乱用に歯止めをかける効果 があります。「本当に継承すべきなのか、それともコンポジションで表現すべきなのか？」を考える機会を自然に与えてくれるのです。

多重継承がなくて困る場面は確かにあります。しかしそれは「多重継承でしか解決できない問題」ではなく、「多重継承なら一行で済んだのに」という 利便性の問題 であることがほとんどです。C# はその利便性と引き換えに、言語全体のシンプルさと安全性を選びました。

まとめ

多重継承は強力なツールですが、Diamond Problem をはじめとする実装上の複雑さを避けられません。C# は C++ や他の言語の経験から学び、クラスの単一継承＋インターフェースの複数実装 という設計を採用しました。

この判断は Anders Hejlsberg の設計哲学 — 「本質的なシンプルさ」と「バージョニングの安全性」の追求 — に根ざした実践的な判断であり、C# 8.0 のデフォルトインターフェースメソッドによって、インターフェースの表現力もさらに強化されています。

C++ からの移行では「できないこと」に目が行きがちですが、制約が より良い設計へのガイドレール として機能することもあります。コンポジション、インターフェース、拡張メソッドを組み合わせれば、多重継承に頼らずとも柔軟で保守しやすい設計は十分に実現できます。

付録: 主要オブジェクト指向言語の多重継承サポート比較

参考として、著名なオブジェクト指向言語が多重継承をどう扱っているかを一覧にまとめます。

多くの後発言語が「クラスの多重継承は非サポート、代わりにインターフェースやトレイト・Mixin で補う」という設計に収束していることがわかります。これは C++ の実践経験から得られた業界全体の教訓が、言語設計に反映された結果と言えるでしょう。