|
■No51468 (OBJ さん) に返信 > ■No51464 (すなふきぬ さん) に返信 >>この設計は、これから本当に作成するプログラムなのか、UMLの課題のような概念的な設計なのでしょうか? > > 本当に作成するプログラムではないのですが、オブジェクト指向の考え方が分かっていないため > どういう設計がベターなのか模索しているところでした。
了解です。では、設計をする段階で注意すべき点から考えていきましょう。
>>このようなプログラムの場合、主役となるオブジェクトは「画像」だと思います。 >>描画処理があるということは、画面なりブラウザなりの描画先のオブジェクトも存在するでしょうし、クラス設計の段階でこれらのオブジェクトがまだ見つけれていないように思います。 > > すいません。ここが良く分かりません。 > 描画先のオブジェクトというのは確かに画面なりブラウザなりあると思うのですが、それは描画クラスとは独立するものなのでしょうか。
これについては、アプリケーションの規模によると思います。 簡単な描画だけで処理が完結するなら画面の中に描画処理を入れても良いと思いますし、複雑な描画処理が必要ならば描画を制御するクラスを独立させるのが可読性を高めると思います。 前者なら「画面が画像を描画する」ですし、後者なら「画面が描画クラスを利用して画像を描画する」だと思います。
>>OBJさんが考えているクラスの中で言えば、「画像管理クラス」が「画像」を管理することになると思います。 > > ということは、画像管理クラスが画像クラスを集約するということでしょうか。 > 画像管理クラス−−−風景画像クラス > | > −−人物画像クラス > | > −−・・・
集約の概念は、コンポジションと混同されることも多く色々な解釈があると思いますが、重要なのは ・「インスタンスの関連」である ・ライフサイクルの依存が両者において存在しない(依存する場合はコンポジション) ことだと思います。 今回のシステムで言えば、「画像」インスタンスをどこで管理するかで関連の度合いは変化すると思います。
> >>通信クラス ・・・通信処理を行うクラス(画像送受信クラスに集約する) >> >>この関係も集約にする必要はないはずです(通信クラスは、画像送受信クラスの送受信処理の間だけ生存すれば良いため) > > 上述の画像管理クラスの考え方が違うとこれも違ってしまうのですが、下記のような使い方は正しいでしょうか。 > 通信クラス−−TCP通信クラス > | > −−UDP通信クラス > | > −−・・・
この図の階層が関係を表しているのか、継承を表しているのかわからないので回答に迷いますが、TCP通信クラスやUDP通信クラスを自作されるのでしょうか? Javaや.NETを利用するのであれば、この辺の通信クラスはフレームワーク側で提供されているものなので、自作しないのであれば初期の段階ではクラス図に書かない方が良いと思います。 クラス設計で重要なことは、作成するクラス間の関係を明確にすることだと思うので、なるべく簡潔に記述することをお勧めします。
> 画像送受信クラスはこの通信クラスを使用するということでしょうか。
ところで、この「通信クラス」の立場はどのような物なのでしょうか? 画像送受信クラスから呼ばれるみたいですが、明確な意味がないのであれば「画像送受信クラス」にまとめることはできないでしょうか?
> 集約は拡張性を上げるために使っているというイメージなのでしょうか。
TCPやUDPは非同期な処理になると思うので、通信クラスの属性としてインスタンスを保持する必要があるかもしれませんが、この場合は単純にプライベートな属性として記述しておくと簡潔にまとまると思います。 (もしくは、通信メソッド(TCP, UDP etc)のみ定義しておく。TCP通信クラスのインスタンスを通信クラスが保持するかしないかは、あくまで実装レベルの話なので外部のクラスから見ると必要ないものなので敢えて記述しない)
|