Hatena::ブログ(Diary)

yvsu pron. yas このページをアンテナに追加 RSSフィード

2004-10-24

Statelessの意味

Stateless BusinessLogicにおけるStatelessの意味が分かりづらいところがあるようなので補足します。

ここでいっている「Stateless」とは、

オブジェクトのメソッドを呼び出す前後で、オブジェクトの状態が変わらない。

ということで、「オブジェクトの状態が変わらない」とは、

オブジェクトインスタンス変数(もちろんstatic変数も)を更新しない。

という意味で使っています。

ある業務ロジックコンポーネントがあって、メソッドMa、メソッドMbをもつとします。Ma、Mbとも引数としてクライアントが入力した状態Sを受け取るとします。

Statelessな場合は、Ma、Mbに依存関係はありません、と以前書いたのですが、実は間違ってますね。m(_ _)mここでいっている依存関係とは、呼び出し順序の依存関係です。

状態Sが更新されない場合は、確かにMa、Mbには依存関係はありません。しかし、MaでSが更新され、MbがMa更新されたことをあてにしている場合、MbはMaに依存しているということになります。

次に、状態Sをコンポーネントの状態として持つ、Statefulな場合を考えてみます。Ma、Mbの依存関係については、Statelessの場合と同様です。ただし、状態Sを引数ではなく、インスタンス変数として持っているため、状態Sを作り出したクライアント専用になります。なぜなら、Thread Safeの問題が出てくるためです。

それに対し、Statelessなら、引数として状態Sを受け取るので、1つのコンポーネントで、多くのクライアントを同時に処理することができます。

Statefulでやる場合、状態Sを持ったJavaBeansをnewして作成し使うことになるでしょう。そうすると、クライアントは、インターフェースではなく、実装クラスに依存することになります。それを避けるために、すべての状態ごとにFactoryクラスを用意するのは、面倒でコストがかかります。

Statelessでやる場合は、実装クラスの生成やDIは、DIContainerがすべて面倒を見てくれます。

こう考えていくと、プレゼンテーション層から最初に呼び出されるクラスは、Statelessにすべきだと思います。その後は、

2パターンに分かれると思います。

リッチな業務ロジックモデルをTransactionScriptと呼ぶのはどうも違和感あります。(^^;


追記:これは、「データと振る舞いは常に分離した方が良い」ということではありません。業務ロジックは、データよりは、業務機能の方においた方が良いと思うということです。複数の業務機能で、同じデータを使うことは良くありますが、ロジックは、業務機能ごとに異なる場合が多いでしょう。