K.Maebashi's BBS

>MAYERさんのはこっちですね。品切れ、中古もなしですねえ… 手に入らないとなると余計にほしくなります。 いろいろと探してみます...。 >>>一瞬納得しそうになりますが、TREE_NODEが、その要素への参照を持てば >>>済む話ですよね。EiffelにはGenericsがあるわけですし。 > >>委譲が面倒でなければ前橋さんのやり方の方が柔軟性ありそうですね。 > >うむむ。私が書いたやり方は、実は普通にコレクションクラスライブラリに >オブジェクトを突っ込む方の意味のつもりでしたが、WINDOWは本質的に >親子関係を持つわけですからadd_child()とかはWINDOW側に付くべきですよね。 ># ていうかWINDOW自身が自分の子を知らないと困るわけで… ># 今回いろいろぼけてました。 > >てなわけでinterfaceにして委譲することになるわけですが、 >面倒だという意見もあるでしょう。 コレクションライブラリにオブジェクトを突っ込むということで Genericsがあるという意味がやっと分かりました。 しかし自分で書いておいて後からよく考えてみると、 1)インターフェース継承による多重継承によりWINDOWを表す方法 2)集約によりWINDOWをもつ方法 の2つでは、若干違いがあると思います。 クラスのクライアント側から見た場合、2)の場合、あくまでも外面は TREE_NODEであり、WINDOWではない訳です。 クライアントクラスに渡す場合、WINDOWとして処理したい場合でも クライアントは、TREE_NODEとして受け取らなくてはならないからです。 TREE_NODEからGetterでWINDOWを取り出し、渡すという方法もありますが、 あまり気楽に渡したのでは参照を保持する意味がありません。 1)と2)は機能的には同じですが、外面という意味では違いそうです。 恐らく一般的に、実装継承と比較すると集約の方が柔軟性あるということですね。 前橋さんのコレクションクラスを利用する方法は一番シンプルだと 思いますが、前橋さん自身がおっしゃってるように、真面目に考えると 本来WINDOWクラス自身に持たせたい機能を他で持つのはあまり 好ましくないかもしれません。 >>テストケースを書く前に決まっているとすると、結局は初めにUMLありき >>なので、テストケース自体単なる動作チェックもしくは、 >>後でリファクタリングをするのだけが目的ということになり、 >>あまりおいしくはなさそうです。 > >うーん、UMLで言えば、クラス図よりは後だけどシーケンス図よりは前というか。 >また、いつでも気楽に自動テストができるなら、それだけでもおいしいと思います。 確かにそうかもしれません。使い方次第ですかね？ ところで、知っていたら教えてほしいのですが、PerlとCのリンク方法で 詳しいページとか書籍とかあったら教えてほしいです。 つまりCのメモリ上にPerlで処理したデータを取得したいのです (外部ファイルとか、ソケットなどを使わずに)。 前橋さんに聞くのはどうかとも思いましたが、特にCのプログラミングのことなら 知らないことないというイメージだったので...。 もし知っていたらで結構です。