- - PR -
オブジェクト指向設計に関する質問
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2006-03-30 21:37
オブジェクト指向設計に関する質問です。
例として以下のようなシステムを開発するとします。 [本の貸出システム] ・会員は本を複数借りることができる。 ・本は本箱に入れて保管される。 ・会員、本、本棚にはそれぞれ一意なIDが割り振られる。 ・会員、本、本箱の情報はDBに保存される。（このシステムから登録・削除等を行える。） ・貸出情報（過去の履歴含む）もDBに保存される。 ・貸出情報には会員ID、本のID、貸出日、返却日が含まれる。 これらのことから、主なクラスとしてまず 会員クラス、本クラス、本箱クラス、DBアクセスクラス、貸出情報が 浮かび上がると思います。 DBクラスには指定したIDを元に本オブジェクトを取得するGetBookメソッドなどがあるとします。 ここで一つ目の質問です。 本と本箱は格納という関連を持ちます。 これを実際にフィールドとして用意する時、いくつか方法が浮かぶと思います。 たぶん、↓に挙げたものの組み合わせのどれかとなりますよね？ 本箱について（このグループをAとしときます） １．本箱には格納している本のオブジェクトのコレクションを持たせる。 ２．本箱には格納している本のIDのコレクションを持たせる。 ３．本箱には格納している本の情報を一切持たせない。 本について（このグループをBとしておきます） １．本には格納先の本箱のオブジェクトを持たせる。 ２．本には格納先の本箱のIDを持たせる。 ３．本には格納先の本箱の情報は一切持たせない。 これらの組み合わせは全部で9種類となりますが、どの組み合わせを採用するのが一般的でしょうか？（それとも周りの設計、やりたいこと等によって最善の組み合わせは変わるのでしょうか？） また、あまり一般的でない組み合わせとか、絶対にやってはいけない組み合わせとかありましたら教えてください。 | ||||||||||||
|
投稿日時: 2006-03-30 22:09
すみません、格納というクラスを用意して本箱のオブジェクトと本のオブジェクトのコレクションを持たせるという方法もありました。
| ||||||||||||
|
投稿日時: 2006-03-30 22:44
本箱クラスに本コレクションを実装する。 本コレクションはインデクサによって参照する。(Count プロパティも設ける) 本クラスには自分を格納している本箱クラスのインスタンスの参照だけを持つ。 _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||||||
|
投稿日時: 2006-03-30 23:02
じゃんぬねっとさん、返答ありがとうございます。
相互参照はあまり使うべきでないという先入観があったので、自分の中ではちょっと意外でした。（よくよく考えるとDataSetとDataTableとか親Formと子Formとか色々使われてますね。そういえば.NETのGCは相互参照しててもちゃんと解放してくれるらしいですし） .NETのGCでは相互参照も問題なく解放処理を行ってくれる以上、相互参照を使用しても全く問題ないということでよろしいでしょうか？ | ||||||||||||
|
投稿日時: 2006-03-30 23:50
変わると思います。 もちろん相互参照でも問題はありませんが、クラスは複雑化します。 本箱クラスがこのシステムでどのように使われるかがわからないので、なんとも言えませんが、 なるべくシンプルに実装するのが私の考えです。 | ||||||||||||
|
投稿日時: 2006-03-31 00:51
大雑把でも良いから、ユースケース分析をしてみましょう。
本の検索、貸し出し、返却、といった辺りが主要業務でしょうか？ この例だと、「この本はどの本棚に収納されているか？」を取得する処理は頻発しても、 「この本棚にはどんな本が収納されているか」を取得する処理は、棚卸しというか蔵書確認 というか、日常的でない作業でしか必要とされないように思われます。 「本棚オブジェクトが本オブジェクトのコレクションを持つ」という実装は非効率的では ないでしょうか？ | ||||||||||||
|
投稿日時: 2006-03-31 01:17
僕もそう思います。 本当に、本そのものや書棚そのものをオブジェクトとした方が、理解しやすいシステムとなるでしょうか？ 現実世界の図書館には図書カードや蔵書目録といったものがありますが、そういったものを視野に入れて「図書館というシステム」を分析しなおしてみた方がいいと思います。
他にも見えない前提や要件があるのかもしれませんが、ここだけ見るとそう思います。 たとえば、このまま真正直に O → R 方向にマッピングしてしまったりすると、非常に取り回しにくいでしょう。 | ||||||||||||
|
投稿日時: 2006-03-31 01:20
burton999さん、coasmさん、返答ありがとうございます。
なるほど、参考になります。 そのシステムにあった設計を心がけようと思います。
ユースケース分析、したことなかったです・・・。あまり重要視していませんでした・・・。早速やります。
確かにそうでした、本の検索、貸し出し、返却だけだと本のコレクションを持つ必要ないですね。 ふと思ったんですが、仮にこのシステムは本の検索、貸し出し、返却だけのシステムとしても、今後システムの機能拡張で棚卸しとかが増える可能性も充分ありえますよね。将来を見越して設計するならば、やはりじゃんぬねっとさんのやり方を初めから適用しとくべきなのでしょうか？（ぅーむ、だんだんわけがわからなくなってきた・・・やはりオブジェクト指向って難しいですね。。。） えっと、あと実は、DBアクセスクラスの位置づけについても質問があります。（同じ例を使用しての質問なので引き続きこのスレで質問させてください） DBアクセスクラスの位置づけとして２通り思いついたのですが、 一つ目は、DBアクセスクラスを会員クラスや本クラスから利用するような設計、 二つ目は、会員クラスや本クラスからはDBアクセスクラスを利用しない設計です。 具体的には、 一つ目の設計では、会員クラスや本クラスにstaticメソッドとしてGetInstance(int id)というようなメソッドを用意し、このstaticメソッドがDBアクセスクラスのGetBookメソッドを呼び出します。他にもDBの更新や削除も会員クラスや本クラスにUpdateメソッド・Deleteメソッドを用意して、これらがDBアクセスクラスのUpdateBookメソッド等を呼び出します。これらのクラス群を利用するFormクラス等からはDBアクセスクラスを直接利用しません。（なんというか、会員クラスや本クラスの裏側に位置するような設計です。） 二つ目の設計では、会員クラスや本クラスからはDBアクセスクラスを利用せず、これらのクラス群を利用するFormクラス等がDBアクセスクラスのGetBookメソッド等を直接利用します。 この二つの設計について、一般的な設計としてはどちらの設計なのでしょうか？やはりこれもケースバイケースなのでしょうか？ #こういう具体的な設計方法を紹介してるサイトになかなか出会ったことがないんですよね・・・。検索方法が悪いだけかもしれませんが・・・。 | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。