id:fumokmmさんに
いやだから具体例でお願いします。私ははてなダイアリーを例にしましたけど、同じ例でも他の例でもいいですから。
と書いたら具体例で回答くださいました。
http://d.hatena.ne.jp/fumokmm/20090502/1241273451#20090502f1
あまりいいものがパッと思いつかなかったのですが一応書いておきます。id:kmaebashiさんの例と同じ、はてなダイアリーについて。
で、ひとつのエントリを示すクラスがこうなっています。
/** エントリを表現するクラス */
class Entry {
private String contents; // 内容
private Listcomments; // コメント
private boolean isTemp; // 一時保存かどうか/** エントリに編集する */
public void editContents() { ...(省略)... }
/** コメントを編集する */
public void editComments() { ...(省略)... }
/** 永続化する */
public void commit() { ...(省略)... }
：
：
：
}
ここで「コメント」がEntryにくっついていますが、実際のはてなダイアリでは、コメントはデフォルトではDiaryに対して付き、「ブログモード」にするとEntryに対して付きます。これははてながもともと「日記」だったものをなんとかブログらしく化粧直しした変態システムだからで、変なのですが、現状の仕様を満たせないのはやっぱりまずいでしょう。
また、確か現状のはてなにも「自分が書いたコメント一覧」を参照できるパーツがあったはずですし、承認したりspamを消したりするコメントの管理画面では、エントリに対するコメント一覧を表示できなければなりません。つまり、「1エントリに対してnコメント」という構造は、確かに(ブログモードにおいて)「記事を表示する」という機能についてはそのとおりなのですが、他の見方もあるわけです。
もちろん、D/B自体はあくまでRDBMSなのであれば、コメントはいろいろな条件で検索できるので、他の見方をするときには別のクラスを介すればいいですけど、少なくともeditComments()がここにあるのはいかにもまずそうですね。
今回の例ははてなダイアリでしたけど、現状の多くの職業プログラマのメシのタネになっている「業務アプリ」の世界においても、
- データはひとまずRDBMSに集積されていて、
- それに対しいろいろな機能を付けるのだけれども、機能は山ほどあり、かつ、将来的にどんな機能が付くのかは予測できない。
という状況は多いのではないでしょうか。なにしろデータは長期にわたって運用されますし。
システムにはどんな機能が付くのか予測できないにも関わらず、クラス設計というのは「ある見方」を想定してしまうので、あまりうまくいかないんじゃないかなあ、と思うわけです。
