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

[Shin <shin@xxxxxxxxxx>]

In article <9909010924.AA12959@xxxxxxxxxx>
Kazuya Maebashi wrote:
>>どんな形状でも二次元空間に表現出来る機能を持たせるべきと判断した
>>らくっつけると思います.
>>データベースに登録されるのはオブジェクトであって、クラスではない
>>ですので、deserializeしたオブジェクトのdraw()を呼ぶ呼ばないは利用
>>者の自由ですね.
>
>ええと、どんな形状でも、こっちのアプリ(またはコマンド)では二
>次元空間に表現出来る機能が要るけれど、こっちのアプリ(または
>コマンド)ではそれは全然使わないかも知れない、という場合につ
>いては、「呼ぶ呼ばないは利用者の自由」としてくっつけてしまえ、
>というご意見であるということでよろしいでしょうか。

「使えることに価値があるならば」ですね.単に、「複数の利用者がdraw()を
利用することが解っていたらShapeに持たせる」という考え方でも、大きな問
題にはならないと思います.
draw()を利用することなくShapeを使うものが圧倒的多数なら特に必要ないの
でしょうけど.
# やっぱり、Shapeにdraw()を持たせるならば、toString()メソッドのような
# 効果を期待したい場合かなという気もします.
# しかし、Shape自身に持っていなくてもその効果は実現可能なので、Shapeに
# 持っていなければならないという理由は全然ないです.
# 持たせても別にかまわない(何とかなる)という程度の意見と思ってください

>>serialversionIDをいじって古いオブジェクトもデシリアライズ可能にす
>>るのかなあ?あまり勉強していませんが.
>
>そうですね。私もあまり勉強していませんが、メソッドが減ろうが
>増えようが、データメンバが変わらない限り、シリアライズすれば
>*基本的には* 同じものが出てくるでしょうから、きっとごまかし
>ようは...
>
>でも、クラスファイルが変わっちゃった時点で、古いバージョンで
>シリアライズしたものを読むのは、なんだか「気味が悪い」感じが
>しませんか?

気持ち悪いですねえ.しかしどうやらこれは避けられない問題のようで、「じゃ
あShapeクラスのサブクラスは直列化される可能性があるから二度と変更しな
いでね」とは言えないですよねえ.
今、この問題が世間ではどう扱われているかはしらないのですが.

>ファイルサイズはともかくとして、このアプリ(またはコマンド)で
>しか使わないメソッド、あのアプリ(またはコマンド)でしか使わな
>いメソッドを、主要なクラスにべたべた取り込んでいくのは、概念
>的に美しくないように思うのです。

でも、全てのアプリケーションが使うメソッドしか持たないというのは変です
よね.使う使わないというよりは、その機能が十分標準的か否かがそこに持つ
べき理由になると思うので、「使わない人がいるから」は持たせないことの理
由にはならないとおもいます.
でも別にこれは反対意見でもなくて、「使う人がほとんどいないから」オプショ
ン機能として別クラスで提供すべきということなら解るので言葉尻の問題です
が...

>データ構造の整合性を維持するために絶対不可欠なメソッドなら、
>Shapeみたいな所に入っていても文句はないんですけれども。

で、人によってはデータを表示する機能は絶対不可欠という視点でそういう設
計にすることもあり、特に悪いことでもないかなあという.

>Shapeはデータベースに格納されるわけですけど、データベースといえば、
>
>・大昔のアプリケーションは、それぞれ勝手な形式のファイルにデー
>  タを保管していた。それらのファイルの間には、重複した情報も
>  あったりして、管理が大変だった。
>・そこで、データベースに情報を全部置いて、アプリはそれを参照・
>  操作するようにした。
>
>というものだったと思うんですが、その場合、データベースに入っ
>ているモノは、各アプリから独立でなければならないのでは?
>
>そうすると、データベースに入っているモノは、外部から参照され
>たり操作されたりする客体に過ぎなくなるわけで、よって各データ
>が主体的に動くオブジェクト指向とは概念が真っ向から対立してそ
>うで、するってえと「オブジェクト指向データベース」というのは、
>名前からして矛盾している存在なような気もしないでもない...

データベースのデータを使うアプリケーションを作る人がみんな同じように
draw()を実装しなければならないといった問題を解消するために、データに対
する標準的な操作までパックして、データベースに入れようというのがオブジ
ェクト指向データベースの考え方かなあと思います.(知りませんが)
draw(Shape)みたいなのがライブラリに存在すれば問題にならないんじゃない
かって気もするので外してるような気もしますが.


続きは会社についてからで.

──────────────────
木下 信＠イデア
この手のネタに弱いんです.
言語仕様の話も大好き(熟知しているわけではないですが)だけど、そこまで手を出したら...
──────────────────