まつもと ゆきひろです

In message "[ruby-list:18852] Re: Why Mix-in? (Re: [book] $*, etc.)"
    on 99/11/23, Toyofuku <toyofuku / juice.or.jp> writes:

|> Ruby本、p.175図4-5と、p.178図4-9の周辺ではいかが？
|
|  ダメです。:-)

そうですか。

|というか。多重継承も Mix-in も使ったことないので
|実感がわきません。

うーん、「使ったこと無いんで実感がわかない」んですから、使っ
てみていただかないことにはどのような説明も無効のように思いま
す。やっぱり経験によって学んでいただかないと。:-)

ともあれ、まず最初に理解していただきたいのはMix-inは多重継承
のサブセットだと言うことです。つまり、「多重継承にできないこ
とがMix-inにできる」というのではないということです。逆に「多
重継承ではまずい設計ができてしまう可能性があるが、Mix-inが強
制されればそれはできない(まずい設計になりにくい)」ということ
ですね。引き算の発想。

gotoであらゆる制御構造が構成できるが現代の言語の多くにgotoが
採用されていないようなものですね。

|どういう流れでこう出力されるのかよくわかって
|ないのですが多重継承にはこの仕掛は入れられ
|ないのでしょうか。またこの仕掛が入れている
|ことによる Mix-in のデメリットはないので
|しょうか。

仕掛けそのものは不可能ではないです、つーか、まったくおんなじ
やり方が可能です。繰り返しますがMix-inは多重継承のサブセット
ですから。が、多重継承はクラス関係の任意のDirected Acyclic
Graph構造を許しますから、この仕掛けが直感に沿う保証はどこに
もありません。一方、単純継承＋Mix-inはそのかなり小さなサブセッ
トですので、直感に沿わない可能性がかなり低いです。

Mix-inにおけるこの仕掛けのデメリットってのは思い付きませんね。
あるのかもしれませんが。

|  「複数回実行」以外の「クラスの挙動が予想しに
|くくなる」具体例とそれを Mix-in で書いたときの
|例の比較などもあるともっとぴんとくると思います。

うーん、実はかなり深いクラス階層が構成されないとこの問題は発
生しないのですが、この問題が発生するような深いクラス階層は、
ほとんどの場合そもそも問題のあるクラス設計ですから、Mix-inに
よって「クラスの挙動が予想しにくくなる具体例」ってのはなかな
か作りにくいんですね。

ちょっと無理矢理な例ですが

  Window
  TitledWindow
  ShadowedWindow
  TitledShadowedWindow
  TerminalWindow
  TitledTerminalWindow
  ShadowedTerminalWindow
  TitledShadowedTerminalWindow

というクラス階層を、Mix-inを使わないで

  Window<Object
  TitledWindow<Window
  ShadowedWindow<Window
  TitledShadowedWindow<TitledWindow,ShadowedWindow
  TerminalWindow<Window
  TitledTerminalWindow<TitledWindow,TerminalWindow
  ShadowedTerminalWindow<ShadowedWindow,TerminalWindow
  TitledShadowedTerminalWindow<TitledTerminalWindow,ShadowedTerminalWindow

と設計するのと、Mix-inを使って

  Window<Object
  Titled(モジュール)
  Shadowed(モジュール)
  TitledWindow<Window; include Titled
  ShadowedWindow<Window; include Shadowed
  TitledShadowedWindow<Window; include Titled, Shadowed
  TerminalWindow<Window
  TitledTerminalWindow<TerminalWindow; include Titled
  ShadowedTerminalWindow<TerminalWindow; include Shadowed
  TitledShadowedTerminalWindow<TerminalWindow; include Titled, Shadowed

と設計するのとどっちが良いかというような感じです。伝わるかな。
上の例でクラス図書いてみると良いかも。

「良い」というのは客観的に示せないのでちょっとつらいですけど。

|  それとクジラの Mix-in の例ですが、哺乳類を主
|に、海棲を従に考えていると思うのですが、別の
|ケースで哺乳類を従に考えることもあるかもしれない
|から module Mammalia にしておこうというように
|何でも module になってしまわないんでしょうか。

それは見方の問題(解決すべき問題のとらえ方)ですから、そうする
のが好ましいと思えばそうすれば良いと思います。が、それで使い
やすいかどうかはまた別の問題なので、結局はバランスのとれたと
ころで収束するのではないかと思います、普通は。

                                まつもと ゆきひろ /:|)