ミックスイン
mix-in 、mixin 、MixIn 。
コードや機能の再利用性を重視したクラスに準ずるコンポーネント。
それを用いるとき必要とされる機構。多重継承を実現できる。というか、当初、多重継承と同義。
単一継承機構の欠点を補うこともでき、Ruby などで採用されている。
SELF でもトレイトとは別に同名、同種の機構が採用されている。--sumim
クラスベース・オブジェクト指向におけるクラスには、
というある意味で相容れない2つの役割りがある。
前者では大きく複雑になりがちで、後者では小さくシンプルであるべき。
前者では継承階層で決まった場所に位置するが、後者では任意の場所で用いられるべき。
そこで、ムーンら('86)は Flavors という機構でこの問題を解決しようとした。
Flavors において flavor は小さく、必ずしも完結している必要はなく、
継承階層のどこへでも「ミックスイン (mixed-in) 」して用いることができた。
このコンポーネントは、インスタンスの生成性より、コードや機能の再利用性を重視したものだと言える。
Traits - Composable Units of Behavior [PDF] より。--sumim
ミックスインの問題点は、それを用いたとき、新しい能力を得たクラスを作ることは容易でも、
新たな再利用性モジュールを作り出す用途には向かないこと。
ミックスインを複数同時に用いるには、その整合性に注意を払わなければならず、
これは利用者に苦痛を強いる。同上文献より。--sumim
- Traits
一見ミックスインだけど、エンティティを継承パスに参加させない点で異なる。比較的積極的にコンフリクトに対応する機構を取り入れている。
プラグインとの違いは?
ああ。これ、ミックスインなんですか…(^_^;)。Self のマニュアルや「The Theory of Objects」でよく目に付く単語だったんですが、なんだろう、なんだろう…と。<調べろっちゅうの もっともだから何かが分かったわけではありませんが(爆--sumim
CUEの理解するところでは、多重継承に於いて、実装の継承とインターフェースの継承を分離する事、と理解しています。
実装はただ一つのクラスから、インターフェースはないか、もしくは一つ以上のクラスから派生するようにすると、設計が楽になるらしいです。--CUE
ありがとうございます。そういう理解でくだんの文献を読み返してみます。--sumim
>「The Theory Of Objects」
今検索してみたんですが、A Theory of Objectsと関係あります?--CUE
あ、すみません。間違って覚えていました。それです。--sumim
このページを編集 (2798 bytes)
|
以下の 7 ページから参照されています。 |
This page has been visited 8860 times.