さっそくたくさんのトラックバックを頂いて
ブログの力を認識中。
とまさしくその通りの一言で説明されちょっとドキリ。
さらにid:tokuryoさんに
ただ、ステートマシン図（状態遷移）を書いて
ステートパターンを適用するというのは
「自然な思考」な気がしています。
それにクラス図を見て業務のイメージが湧きやすいですし。
とトラバを頂きました。
基本的には、オブジェクト指向に気をつけよう程度の気持ちだったのですが、
技術的な部分も嫌いでは無いので、tokuryoさんのクラス図について検討
したいと思います。
レンタルビデオの状態をステートパターンした場合に
以下のような問題が出てくると思います。
- レンタルディスククラスは貸し出し操作時にエラーをキャッチして貸し出し中の処理をしたりし、結局レンタルディスククラス側に条件分岐が発生してしまう。
- 貸し出し状態クラスに貸し出し可能かどうかの条件チェックメソッドが必要になってくる。
- 未貸し出しの返却すると貸し出し中の貸すメソッドは何もすることが無いのにメソッドを実装する必要がある。
という点で、メンテナンスが発生し
オブジェクト指向がうまく活用されない状態に陥ると思います。
これはさらに状態が３つ４つと増えると顕著になります。
注意点は
ステートマシン図（状態遷移）＝ステートパターン
ではないというところ。
「未貸し出し」と「貸し出し」という状態があって
これは何も問題が無い状態です。
たとえば、「未貸し出し」と「貸し出し」の
どちら状態においてもレンタルディスククラスから見て
まったく同じものとして扱いたいが、それぞれの状態によって
実際にやる処理が違う場合に
始めてステートパターンを適用するようになります。
ステートパターンで隠蔽化するのは
状態ではなくて状態に依存する処理ってとこが重要です。
レンタルディスククラスからみて
状態によって違う処理が必要になってしまうと
その分イレギュラーな処理が発生し
ステートパターンが有効利用されなくなります。
状態に依存する処理を隠蔽化する必要が無ければ
ステートパターンを使用するメリットは無いのではないでしょうか。
たぶん．．．
