vieweditattachhistoryswikistopchangessearchhelp

ミックスイン

mix-in 、mixin 、MixIn 。

コードや機能の再利用性を重視したクラスに準ずるコンポーネント。
それを用いるとき必要とされる機構。多重継承を実現できる。というか、当初、多重継承と同義。
単一継承機構の欠点を補うこともでき、Ruby などで採用されている。
SELF でもトレイトとは別に同名、同種の機構が採用されている。--sumim




クラスベース・オブジェクト指向におけるクラスには、
というある意味で相容れない2つの役割りがある。
前者では大きく複雑になりがちで、後者では小さくシンプルであるべき。
前者では継承階層で決まった場所に位置するが、後者では任意の場所で用いられるべき。
そこで、ムーンら('86)は Flavors という機構でこの問題を解決しようとした。
Flavors において flavor は小さく、必ずしも完結している必要はなく、
継承階層のどこへでも「ミックスイン (mixed-in) 」して用いることができた。
このコンポーネントは、インスタンスの生成性より、コードや機能の再利用性を重視したものだと言える。
Traits - Composable Units of Behavior [PDF] より。--sumim


ミックスインの問題点は、それを用いたとき、新しい能力を得たクラスを作ることは容易でも、
新たな再利用性モジュールを作り出す用途には向かないこと。
ミックスインを複数同時に用いるには、その整合性に注意を払わなければならず、
これは利用者に苦痛を強いる。同上文献より。--sumim


プラグインとの違いは?

ああ。これ、ミックスインなんですか…(^_^;)。Self のマニュアルや「The Theory of Objects」でよく目に付く単語だったんですが、なんだろう、なんだろう…と。<調べろっちゅうの もっともだから何かが分かったわけではありませんが(爆--sumim

CUEの理解するところでは、多重継承に於いて、実装の継承とインターフェースの継承を分離する事、と理解しています。
実装はただ一つのクラスから、インターフェースはないか、もしくは一つ以上のクラスから派生するようにすると、設計が楽になるらしいです。--CUE

ありがとうございます。そういう理解でくだんの文献を読み返してみます。--sumim

「The Theory Of Objects」
今検索してみたんですが、A Theory of Objectsと関係あります?--CUE

あ、すみません。間違って覚えていました。それです。--sumim

このページを編集 (2798 bytes)


Congratulations! 以下の 7 ページから参照されています。

This page has been visited 8874 times.