Mix-Inが必要な理由
注：ここでは"Mix-In"を言語仕様ではなく、Mix-In本来の語義である「仮想継承時の約束事」という意味で使っています。
クラスＸ、Ｙ、Ｚを、ポリモーフィズムクラスとして使いたいとします。このクラスはメソッドA,B,Cを実装する必要があります。通常であれば、メソッドA,B,Cの宣言を持つインターフェイスクラスＩ（C++では純粋仮想クラス）を作成し、ここからＸ，Ｙ，Ｚを派生させて使います。
さて、クラスＸ、Ｙの内、メソッドのA,Bの実装が全く同じだったとします。当然コードを共有したいですよね。しかし、インターフェイスクラスには実装が書けません（C++では可能ですが、ここでは置きます）。通常の解決策はメソッドB,Cの実装を書いたクラスImpleを作成し、クラスＸ，Ｙに集約として持たせます。
そして、X::A(),Y::A()がImple::A()を、X::B(),Y::B()がImple::B()を呼び出すようにします。これを「Impleの機能をＸ，Ｙに委譲する」と言います*1。これによって、A(),B()の実装が共有されます。ちょっと考えればわかりますが、メソッド数が増えると非常にめんどくさい作業になります*2
そこで、A(),B()のメソッドを持つMix-InクラスＭを作り、これをクラスＸ、Ｙに継承させる事にします。これなら、委譲コードを記述する必要がありません。ところが、これだとI::A(),I::B()とM::A(),M::B()が競合してしまって、コンパイラが通りません*3。
結果として、クラスＸ、Ｙは以下のように全く同じ継承を持っているにも関わらず、ポリモーフィズムを使ってインターフェイスを共有することが出来ないという現象が発生ます。
- IとＭを継承したクラスＸ（メソッドA()，B()，C()を持つ）
- IとＭを継承したクラスＹ（メソッドA()，B()，C()を持つ）
また、以下のクラスも、Ｘ、Ｙと公開するメソッドは同じ筈なのに、やはり共有することが出来ません。
- Iを継承したクラスＺ（メソッドA()，B()，C()を持つ）
残念ながら、C++ではこれを解決する手段がありません*4。近代的な言語であれば、Mix-Inを言語仕様として採用する事でこの辺の解決手段が用意しています。例えば、２カ所から継承したメソッドを繋ぎ変える構文（インターフェイス名のエイリアシング）とか、Mix-Inを特別な継承形式と捕らえる（RubyのModule構文）とか。
これ、一つ疑問なのは、静的な言語では解決不可能なのかな？ 、と。
どうなんだろう……。よくしらない
