[jfriends] Re: データベースに格納するデータオブジェクトに持つ機能(Re:CADのクラス構造)

[Kazuya Maebashi <maebashi@xxxxxxxxxx>]

前橋です。

Shin さん:
>ShapeサブクラスがShapeRunTimeを知っているわけではなく(データベー
>スから取り出してから外から付けるとのことなので)、各組織がそこの独
>自の実装を付けるわけですね.

そうです。

>その場合、
>In article <37cdd7be.3692.87cced020f2c6377@xxxxxxxxxx>
>Shin wrote:
>>    :
>>  otherYYYY(shape);                     // 特殊な操作の場合
>>    :
>と前橋さん案は同じことかと思います.

ええっ、ちと異論が(^^;

>まず、LineRunTimeForDrawer等をShapeのサブクラスたちに関連付ける処
>理が必要なわけですが、これを行うには結局、
>if (shape instanceof Line) {
>  shape.runtime = new LineRunTimeForDrawer();
>} else if () {
>}
>みたいな事が必要になってしまいます.

ええと、Lineのコンストラクタでくっつければいいかと思ってたん
ですが(Javaのデシリアライザってコンストラクタ呼ぶんだっけ)、
よく考えたら、Lineのコンストラクタが「draw()するアプリケーショ
ン」に依存してはいけないですね。

でも、オブジェクトを構築するアプリによって、くっつけるオブジェ
クトを変えることぐらいは、手があると思うんですけれども。それ
こそShapeRunTimeの生成インタフェースをグローバル変数渡しにし
てでも。

>で、Shapeにメンバを持つ形だとその後Drawerを使う時に、
>
>(LineRunTimeForDrawer)(shape.runtime).draw();
>
>なんてしないといけないので、それなら、

ダウンキャストは、(RunTimeForDrawer)shape.runtime
まででいいと思うのですが、如何?

これなら、少なくともLineかRectかという else if の山は書かな
くてすみます。

>利用者は「ShapeRunTimeというクラスをサブクラス化して、独自の実装
>を書き、Shapeに実行時に自分で設定して、narrowing castして機能を呼
>び出す」という約束を守れるのでしょうか?

サブクラスを定義して、Shapeにくっつける所までちゃんとやれば、
ダウンキャストでヘマすれば例外でコケるので、守らざるを得ない
というか(^^;

あ、draw()を呼ぼうとした時点でコンパイラに怒られるから、実行
時まで待つ必要はありませんね。

>別の観点から見て、ShapeRunTimeには実行時のみ使える基本機能も持た
>せることが考えられますよね.
>それと同程度にdraw()インターフェイスの必要性があれば、
>ShapeRunTime#draw()という(抽象)インターフェイスも書いておけば、
>narrowing cast無しで呼び出せます.

これは、そうだと思います。そして、各アプリの特化したものだけ、
ShapeRunTimeのサブクラスに実装すればいいわけです。

>>使わないメソッドがShapeFunctionにあるということは、あっちの
>>アプリを改造すると、こっちのアプリにも影響が出るということに
>>なりませんか? javacの場合リコンパイルが要るかどうかはよく知
>>りませんけど。

>うーんとこの場合のShapeFunction実装クラスは、Shapeサブクラスと同
>様に複数のアプリケーションから使われるクラスライブラリの位置付け
>ですね.

了解しました。

>        アプリケーションに独自の実装は...の部分(上に引用しました)
>にもあるようにShapeFunctionとは独立して作らざるを得ないと思います.

先程のotherYYYY()ですね。で、LineやRectをinstanceofするelse
if の山についてはあきらめる、ということですか。

そうすると、Shapeにruntimeを持つ必要もなくなるのですが...

でも、どっちみち、transientなメンバは何やかやで要りそうな気
がします。たとえば、Windowsなら、CPenなんてオブジェクトがあっ
て、こいつで描画属性を指定するわけですが、実装によっては、実
行時には各ShapeにCPenを保持させときたいと思うかも知れません。

>ある利用者しか使わない実装ですと、ShapeRunTimeのサブクラスである
>必要性もとくにない気がするという点と、
># 複数扱うかもしれないShapeと一対一にくっつけて同時に引き渡したり
># できることに意義があるということならわかります.

Shapeはたいてい大量にあるでしょうし、Shapeの実行時属性は
Shapeごとに持ってないと管理が大変ですし...

Shapeが具体的にLineかRectかってことにより動作を変えよう、な
んてことも考えると...

># アプリケーション側で同時には一つずつしかShapeRunTimeサブクラス
># 相当の機能を使わないなら、先に書いたような単なるメソッドで良い
># と思います.

ええと、ShapeRunTime(のサブクラス)のインスタンスは、Shapeの
インスタンスの数だけ作るつもりでした。

>私の案はアプリケーション側の行う実装ではなく、Shapeに関連するクラ
>スライブラリの設計に関する話だったというあたりですね.

そういうことでしたら、了解です。

------------------------------------------------------------
  前橋 和弥                             maebashi@xxxxxxxxxx
  中部ソフトエンジニアリング(株)
    〒450 名古屋市中村区名駅4-10-25(名駅IMAIビル 5F)
    Tel:(052)583-4511(代) 内線 252 Fax:(052)583-4566
------------------------------------------------------------