河野真治 @ 琉球大学情報工学です。

In article <egumk2$53t$1@caraway.media.kyoto-u.ac.jp>, 神戸 隆行 <kando@nerimadors.or.jp> writes
> interfaceだけ継承して実装が継承したいときはフィールドに持つというのじゃ
> だめだったんですか？

GUI で(今回は)余計な機能をコンストラクタで立ち上げちゃってい
るので、それを落とさないといけないんです。この手の引き算は継
承では難しい。まぁ、もちろん、main は、こちらで全部再実装し
て部品だけ使うってのでもいいんだけどさ。

> コンストラクタ内にごちゃごちゃあるのは初期化にいろいろ面倒な制約があって
> そういう界面を見せたくなかったとかではないんでしょうか？

デモプログラムですからね。実際、比較的小さい修正で、継承できた
ので、単に手を抜いただけでしょう。

> またその当たりのカスタマイズ容易性に関する設計方針は、そのライブラリが想
> 定する利用者群との兼ね合いもあると思います。Javaにはマルチメディア・フ
> レームワークとかいうより本格的っぽいパッケージも別にあるようですし。

ほほう。見てみます。

> パッケージは階層構造になってて入れ子の内側にあっても
> 独立の別パッケージになっちゃうので。外側と関連が強い内側クラスを作るとき
> には入れ子クラスのほうが自然です。特に入れ子になっているクラスのオブジェ
> クトを単体で利用者に提供する意思のないときは。

自然の意味にもよるけどね。

Inner Class のうれしさは、外のクラスのインスタンスを「制限なく」
いじれるところにあるわけなんだけど、再利用性に関しては最底です。
Model/View が、Control をInner Class として持つという手法なんだけど、
awt のあほさを逃げる方法としてはだめだめだと思う。HogeModel, HogeControl
でいいと思うんだけど。

しかも、実際には、別ファイルのHoge$Control.class が出来ちゃうわけで、
ファイルの配置的な利点しかないみたいですね。実装上は、「単なる
別々なクラス」として処理されているらしい。僕は以下の定理があると思う。

   Inner Class で出来ることは、Inner Class なしで、よりエレガントに
   実現できる

> 外部から迂闊に使われると内部状態に不整合が起こる
> 利用条件のきつい内部メソッドやフィールドって時々あるんですが…。
> ないですか？

それをprivateにすると、Sub class 側での整合性は、「また、Sub
class 側で独自に実装する」しかないですよね。利用条件がきつい
ほど、Sub class 側での調整が出ると思う。Sub class の動作が親
クラスと衝突するときに、親が全部解決してくれるならいいんだけ
ど、それは、普通は不可能です。

---
Shinji KONO @ Information Engineering, University of the Ryukyus
河野真治 @ 琉球大学工学部情報工学科