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

[Toru Takahashi <torutk@xxxxxxxxxx>]

高橋です。

部分最適は全体最適とはかならずしも一致しないのですが。

前橋さん：
>この場合、何十万、何百万行とある大規模なプログラムの、かなり
>の部分が Shapeクラスを使用する筈です。だとすれば、draw()を
>Shapeに入れてしまうと、draw()の実装をちょっといじっただけで、
>そういう箇所全てに影響を与えてしまいます(javacの場合、どうい
>う規則で再コンパイルしているのか私はよく知らないのですが、
>C++でmake使ってたら、フルコンパイルが走る所です)。その大半は、
>draw()を呼んでるわけでもないだろうに、です。
>
>まして、CADなら、Shapeの大群をデータベースとして保存して、い
>ろいろなプログラムでそれを利用すると思うのですが、中には、
>画面描画なんてしないものもある筈です。何か計算してファイルを
>吐くだけとか。
Shapeから派生するクラスツリーのインスタンスに対するユースケース
を考えます。これはシステム（アプリケーション）によって異なります。
上述の場合、Shape派生クラスに対するdraw操作を統一的に扱いたい
アプリケーションと、Shape派生クラスについて保存管理し、他のアプリ
へ配布するようなアプリケーションと、２つのユースケースが見えます。
部分最適を考えると、前者はShapeにdraw操作を持たせる設計が、後者は
アプリケーションのライフサイクルを越えて保存管理していけるように
属性と最低限の操作だけ持ったクラスにする設計がよいのでしょう。
両方に適合する設計を考えると、draw機能や2次元データを別クラスに
委譲させる方法もあります。後者についてはXML等のプログラム言語から
独立性の高い方式で保存管理するとよさそうに思えます。

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

結局すべての変更要因に対応できる設計はないので、もっとも変更可能性
が大きい要因には容易に適応できる設計を採用するのが現実ではないで
しょうか？　変更可能性と変更時の作業量とからリスクコストを算出して、
このコストと、変更に対応した設計を行う追加コストとを比べてトレード
オフします。
今回の問題では、Shape派生クラスを次々追加する可能性はかなり高いが、
グラフィックスライブラリ変更可能性は低いと決断すれば、後者への依存
性を断ち切る設計までは不要となります。全てはケースバイケースなので
すが・・・


------
Toru Takahashi
torutk@xxxxxxxxxx
http://www.alles.or.jp/~torutk/