[jfriends] Re: [jfriends] CADのクラス構造

[Shin <shin@xxxxxxxxxx>]

In article <9909010455.AA02923@xxxxxxxxxx>
Kazuya Maebashi wrote:
>でも、CADなどの大規模なアプリケーションで、そのシステムの根
>幹をなすようなデータ構造に対し、draw()なんてもんをくっつけて、
>本当にいいのでしょうか?

付けても切り離してもよいと思います.

>この場合、何十万、何百万行とある大規模なプログラムの、かなり
>の部分が Shapeクラスを使用する筈です。だとすれば、draw()を
>Shapeに入れてしまうと、draw()の実装をちょっといじっただけで、
>そういう箇所全てに影響を与えてしまいます(javacの場合、どうい
>う規則で再コンパイルしているのか私はよく知らないのですが、
>C++でmake使ってたら、フルコンパイルが走る所です)。その大半は、
>draw()を呼んでるわけでもないだろうに、です。

実装ですか?draw()はインターフェイスですので特定の具象クラスの実装
が変わっても(コンパイルというレベルでは)何も影響は無いですよね.
インターフェイスが変わった場合ということですね.

>まして、CADなら、Shapeの大群をデータベースとして保存して、い
>ろいろなプログラムでそれを利用すると思うのですが、中には、
>画面描画なんてしないものもある筈です。何か計算してファイルを
>吐くだけとか。

どんな形状でも二次元空間に表現出来る機能を持たせるべきと判断した
らくっつけると思います.

データベースに登録されるのはオブジェクトであって、クラスではない
ですので、deserializeしたオブジェクトのdraw()を呼ぶ呼ばないは利用
者の自由ですね.

ただし、ここでさっきの「drawの実装が変わったら」の問題が出る可能
性がありますね.
サブクラスも同じようにデータベースに格納するとなると、オブジェク
トデータベースになると思いますが、その場合シリアライズされたオブ
ジェクトになりますもんね.
クラスが再コンパイルされてバージョンが変わったら、を考えると厄介
です.
serialversionIDをいじって古いオブジェクトもデシリアライズ可能にす
るのかなあ?あまり勉強していませんが.

>ついでですが、draw()をShapeに実装したとして、そのdraw()の中
>で、たとえばAWTなりJava2DなりJava3Dなりの機能を使ってしまっ
>たら、Shapeが、いつか廃れるかもしれない特定のグラフィックラ
>イブラリに依存することにもなります。

こちらですね.上に書いたようにどんな形状でも(toStringみたいな感覚
で)二次元空間(には限らないが特定の空間)に自分を表現出来た方が良い
という場合はくっつけますが、その必要性が特に無く、将来的に3次元空
間に描画する機能などの拡張を考慮する場合は、Shape#draw()は使われ
なくなる可能性があります.
その時に(上に書いた事と少し矛盾しますが)全く使われないメソッドの
ためにclassファイルサイズを食うのは嫌だということであれば、Shape
のサブクラス群と一対一になるDrawインターフェイスの実装クラスを用
意することになると思います.
# データベースの格納サイズは得に変わらないので別に残っててもいい
# 気はしますが.

# ShapeにはDrawインターフェイスの実装クラスを返すfactory methodを
# 用意しておけばよいのでは無いでしょうか.
# そして、描画処理では
# shape.getDraw().draw2DScreen(....);
# shape.getDraw().draw3DScreen(....);等

Drawインターフェイスに新しい空間への描画機能が追加されるなどの拡
張を施しても、逆に機能を削除しても、Shapeには影響は無いですね.
でも、インターフェイスが変われば、Shapeのサブクラス数に相当する
Drawの実装クラスの変更/再コンパイルは結局必要ですが.

──────────────────
木下 信＠イデア
──────────────────