- PR -

オブジェクト指向設計に関する質問

«前のページへ 1|2|3 次のページへ»
投稿者投稿内容
coasm
大ベテラン
会議室デビュー日: 2001/11/26
投稿数: 237
投稿日時: 2006-03-31 01:35
「棚卸し機能も実装してよ」という意味で「増える」可能性は大ですが、
「一時間毎に棚卸し処理を行う」という意味で「増える」可能性はないでしょう(笑)

「本棚オブジェクト」から「本オブジェクト」をたぐる際には、
「本データベース」を全件検索するということで、何ら問題ないでしょう。

機能拡張に備えて、「本棚オブジェクト」に「get本コレクション」を持たせるのは当然の発想
ですが、実装としては「このメソッドが呼ばれることは非常に稀なので、呼ばれた時点で泥縄的に
コレクションを作る」のが正しいと思います。
よこけん
大ベテラン
会議室デビュー日: 2006/01/31
投稿数: 216
投稿日時: 2006-03-31 01:56
渋木宏明(ひどり)さん、coasmさん、返答ありがとうございます。

引用:
渋木宏明(ひどり)さんの書き込みより

本そのものや書棚そのものをオブジェクトとした方が、理解しやすいシステムとなるでしょうか？

現実世界の図書館には図書カードや蔵書目録といったものがありますが、そういったものを視野に入れて「図書館というシステム」を分析しなおしてみた方がいいと思います。


そもそも、用意すべきクラスと不要なクラスを見極めるべきなのですね。

引用:
渋木宏明(ひどり)さんの書き込みより

他にも見えない前提や要件があるのかもしれませんが、ここだけ見るとそう思います。


すみません、ここだけ見てもらって構いません。前に関わったシステムを元に例を作ったのですが、あまり細かくは練ってないので・・・。


引用:
coasmさんの書き込みより

「棚卸し機能も実装してよ」という意味で「増える」可能性は大ですが、
「一時間毎に棚卸し処理を行う」という意味で「増える」可能性はないでしょう(笑)

「本棚オブジェクト」から「本オブジェクト」をたぐる際には、
「本データベース」を全件検索するということで、何ら問題ないでしょう。

機能拡張に備えて、「本棚オブジェクト」に「get本コレクション」を持たせるのは当然の発想
ですが、実装としては「このメソッドが呼ばれることは非常に稀なので、呼ばれた時点で泥縄的に
コレクションを作る」のが正しいと思います。


すみません、意味を履き違えてました。棚卸しがあっても、頻繁に使わないんだったら常時本コレクションを所持する必要がないわけですね。大変勉強になります。
渋木宏明(ひどり)
ぬし
会議室デビュー日: 2004/01/14
投稿数: 1155
お住まい・勤務地: 東京
投稿日時: 2006-03-31 02:31
引用:

そもそも、用意すべきクラスと不要なクラスを見極めるべきなのですね。


「何をクラスとするべきか」の最終判断が設計者任せになってしまっているのがオブジェクト指向の難しさだと思います。

即物的なマッピングをしてしまうと、余分な実装や困難な実装を行う羽目になるので、ある程度実装を踏まえた上で「何をクラスとするべきか」を考えないと、後工程で困ることになります。
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2006-03-31 07:39
引用:

けんじさんの書き込み (2006-03-31 01:20) より:
#こういう具体的な設計方法を紹介してるサイトになかなか出会ったことがないんですよね・・・。検索方法が悪いだけかもしれませんが・・・。

UML よりも、実装レベルに近い話になるので、理論家はあまりこういうったことに興味がないのだろうと思います。でも、プログラマーとしては非常に重要な議論になるはずですが、たしかに、なかなかないですね。

また、RDB(RDBMS) を使う、使わない、はオブジェクト指向とは切り離して考えたほうが楽です。RDB という非常に制約(リレーションありき)の強い環境を前提にして考えると、オブジェクト指向云々は使いにくいものになります。RDB を考えているといつのまにか話が O/R マッピングの話になってしまいます(それはそれでアリでしょうけど)。

・本棚が本を持つ
・本が本棚を持つ
・両方で持ち合う
・格納クラスを作る
は、どれもありえます。検索しやすくするため、あるいは、速く検索したい、などという要求が強いと「両方で持ち合う」やりかたが良いのかもしれませんが、これはインデックスの実装方法の話に近くなり、これもやっぱりオブジェクト指向からは離れて行く話かもしれません。

また、図書館ではありませんが、たとえばアマゾンの物流センターの中の本棚の使い方を見ると、こっちは「格納クラス」のほうが実態に近いのかもしれません。本と本棚の結び付きが疎遠であり、とりあえず空いている本棚に本を無造作に入れて、その結び付きをバーコードで管理していました。
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2006-03-31 07:55
私もコーディング時に常に迷うのですが、こういう場合は、まずは「格納クラス」を作ることを考えたほうが良いです。自由度が高く、いろいろなケースでも破綻なく使えます。
しかし、これはコストが大きいので、必要に応じて、「本棚が本を持つ」か「本が本棚を持つ」にしてしまいます。しかしこれは妥協の結果でそうしたのだ、と意識しながら使います。検索を速くしたければこの変形で「両方で持ち合う」もありでしょう。
しかし、これらで使いにくければ、また「格納クラス」に戻します。

なぜ「格納クラス」が良いのかと言えば、このクラスがあると、非常にものごとをバーチャルに扱えるからです。たとえば、本が巨大で、1つの本棚に納まらなくて、2つの本棚を使う場合とかです。あるいは、仮想商店街みたいな仮想図書館を考えた場合、人ごとに本棚にどんな本が入っているかを管理したい時は、人ごとに「格納クラス」のインスタンスを切り替える、みたいなことが柔軟にできます。
しかし、前述のようにコストが高い。自由度の高さを取るか、コストの低さを取るか、で決めます。
Ｒ・田中一郎
ぬし
会議室デビュー日: 2005/11/03
投稿数: 979
投稿日時: 2006-03-31 10:20
僕は「何があると便利か？」を先に考えちゃいますね。


  • この人は、今何の本を借りているのか？
  • この人が、今までどんな本を借りたのか？
  • この本箱には、今、どんな本があるのか？
  • この本は、今誰が借りているのか？
  • この本は、今どの本箱にあるのか？
  • この本は、今まで、どの人に、どれだけの期間貸し出されて来たのか？


すると、これらの情報を取得したり管理するためのクラスは、どのようにするのが良い
のかが何となく見えてきて、後は、コーディングしては手直ししたり、別のクラスに分
けたりの繰り返しです。
データベースを絡めるのなら「データ構成をどうするか？」と考えるより、必要な情報
を都度データベースから取得してコレクションや構造体に入れて返すやり方を取りますね。
データベースから読んでコレクションに入れても、次の瞬間貸し出し処理が入って情報
が変わる恐れがありますから。
ちいにぃ
大ベテラン
会議室デビュー日: 2002/05/28
投稿数: 244
投稿日時: 2006-03-31 12:07
2006/01に出版されたプレファクタリング―リファクタリング軽減のための新設計が参考になるかも。
モデリングの意味（意義）はUMLによるオブジェクト指向モデリングセルフレビューノートかな。
vincent
大ベテラン
会議室デビュー日: 2004/07/09
投稿数: 142
投稿日時: 2006-03-31 12:26
オブジェクト指向から脱線しますが…

貸し出し業務デザインの定石としては、ここで「本」といわれているものは
「(a)カタログ[目録]」と「(b)本そのもの[実体]」に分けて考えるのが有用です。

検索や履歴表示には(a)、本棚への配置や顧客への割り当てには(b)を使います。
«前のページへ 1|2|3 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）