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

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

即物的なマッピングをしてしまうと、余分な実装や困難な実装を行う羽目になるので、ある程度実装を踏まえた上で「何をクラスとするべきか」を考えないと、後工程で困ることになります。

unibonさんの書き込みより

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

unibonさんの書き込みより

私もコーディング時に常に迷うのですが、こういう場合は、まずは「格納クラス」を作ることを考えたほうが良いです。自由度が高く、いろいろなケースでも破綻なく使えます。
しかし、これはコストが大きいので、必要に応じて、「本棚が本を持つ」か「本が本棚を持つ」にしてしまいます。しかしこれは妥協の結果でそうしたのだ、と意識しながら使います。検索を速くしたければこの変形で「両方で持ち合う」もありでしょう。
しかし、これらで使いにくければ、また「格納クラス」に戻します。

Ｒ・田中一郎さんの書き込みより

僕は「何があると便利か？」を先に考えちゃいますね。


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



すると、これらの情報を取得したり管理するためのクラスは、どのようにするのが良い
のかが何となく見えてきて、後は、コーディングしては手直ししたり、別のクラスに分
けたりの繰り返しです。

ちいにぃさんの書き込みより

2006/01に出版されたプレファクタリング―リファクタリング軽減のための新設計が参考になるかも。

vincentさんの書き込みより

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

検索や履歴表示には(a)、本棚への配置や顧客への割り当てには(b)を使います。

DBアクセスクラスの位置づけとして２通り思いついたのですが、
一つ目は、DBアクセスクラスを会員クラスや本クラスから利用するような設計、
二つ目は、会員クラスや本クラスからはDBアクセスクラスを利用しない設計です。

具体的には、
一つ目の設計では、会員クラスや本クラスにstaticメソッドとしてGetInstance(int id)というようなメソッドを用意し、このstaticメソッドがDBアクセスクラスのGetBookメソッドを呼び出します。他にもDBの更新や削除も会員クラスや本クラスにUpdateメソッド・Deleteメソッドを用意して、これらがDBアクセスクラスのUpdateBookメソッド等を呼び出します。これらのクラス群を利用するFormクラス等からはDBアクセスクラスを直接利用しません。（なんというか、会員クラスや本クラスの裏側に位置するような設計です。）

二つ目の設計では、会員クラスや本クラスからはDBアクセスクラスを利用せず、これらのクラス群を利用するFormクラス等がDBアクセスクラスのGetBookメソッド等を直接利用します。

この二つの設計について、一般的な設計としてはどちらの設計なのでしょうか？やはりこれもケースバイケースなのでしょうか？