- - PR -
状態をクラスに
1
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2007-06-05 13:23
VS2005(VB)
こんにちは。いつも参考にさせていただいています。 オブジェクト指向の設計において、モノをクラスに、コトをメソッドに、 要素をメンバ変数にすることで、柔軟性や保守性を高めることができると よく書籍等に書いてあります。 基本的に私もそのようにクラスを配置しているのですが、 場合によっては、状態をクラスにしたほうがいいのでは? などと感じることがあります。 例えば、2種類ある品物があってそれらは名前が違うくらいで変わりはありません。 ただ、新規、再依頼、受注前、出荷前、出荷後で同じ処理(例えば、価格変更)を した場合、それぞれによって価格変更の内容が違ったような場合、 ”新規”というクラスを作って、スーパークラスに”価格変更”メソッドを設定して オーバーライドさせることで、すっきりとしたコーディングができるのではないかと 感じています。 皆様、どうされているか教えていただけますか。 | ||||
|
投稿日時: 2007-06-05 13:27
GOFのデザインパターンは一通り勉強されたほうがいいです。
State パターンデザインパターン[モデリング] -TECHSCORE- http://www.techscore.com/tech/DesignPattern/State.html | ||||
|
投稿日時: 2007-06-05 15:41
迷いますね。 「すっきりとしたコーディング」という点から言えば、おっしゃるようなメソッドのオーバーライドに傾くかもしれません。 一方、状態遷移という点から考えると、タイプXのサブクラスAのインスタンスを、状態が遷移したからサブクラスBにするということは動的にはできず、クラスBのインスタンスを新たに new しなければなりません。もっともこれらのインスタンスはタイプXの変数で管理すればよいので、とくにダメというわけでもないとは思いますが、状態が遷移するたびに new して用済みのものは参照しない、というのはパフォーマンスのコストの面だけでなくなんとなく気になります。 私としては、なるべくなら if/switch で切り分けたほうがいいような気がします。 -- unibon {B73D0144-CD2A-11DA-8E06-0050DA15BC86} | ||||
|
投稿日時: 2007-06-06 10:30
burton999さん、unibonさん レスありがとうございました。
早速、Stateオブジェクトのサンプルをコーディングしてみて、 どのようなものか確かめてみました。 Stateオブジェクトを作成することにより、クラスの数は増えますが、 とてもシンプルなコーディングが出来、柔軟性も高くなると感じました。 私は、オブジェクト指向で出来るだけ設計・実装したいと考えていますので、 今回はStateオブジェクトを使ってみようと思います。 | ||||
|
投稿日時: 2007-06-07 17:01
自己レスです。
DBはOracleを使用しているのですが、 Stateオブジェクトなのですが、更新系の処理(今回で言えば価格変更) に限った話ですと、ストアドを作って、パラメータでモード分けしてしまうと、 コーディングはもっともすっきりとしたものになるのではないかと思ったのですが、 いかがでしょうか。 ストアドの中身が冗長化するという問題が新たに発生するかもしれませんが、 設計や実際のコードがすっきりすれば、 そちらのほうがいいかもしれないと感じています。 |
1