Stateless BusinessLogicパターン

Stateless BusinessLogicパターン。
これは、変更が多く、複雑な業務システムを開発するための
銀の弾丸だ。しかし、幻ではない。
レガシーなオブジェクト指向の終焉を告げるパターンと
いってもいいだろう。


関連のあるデータと振る舞いを1つにまとめる。
これはオブジェクト指向の最も重要な原則の1つだ。
しかし、例外がある。それは、振る舞いに変更が多い場合だ。


業務システムを開発するとき、永続的なデータは、
比較的安定しているのに対し、業務ロジックは、
ばんばん変更が入る。
この2つを一緒にするとクラスは安定しない。
ホットスポットは切り離せ
この原則の通り、永続的なデータと業務ロジックは
分けた方が良いだろう。


業務ロジックからデータを分離することで、
Statelessにする準備は整った。
それではなぜ、Statelessにすることが複雑な業務システムを
開発するための銀の弾丸なのだろうか。


Statelessにするとメソッド間の依存関係を0にできる。
あるメソッドの呼び出しが、別のメソッドに影響を与えることはない。
例えば、100のメソッドで構成される複雑なロジックがあったとしよう。
実際に起こる可能性のあるメソッドの組み合わせは
1,000,000パターンあるとする。
すべてのパターンをテストするのは不可能に近い。
しかし、業務ロジックがStatelessなら話は簡単だ。
組み合わせを考えることなく、100のメソッドを単体で
きちんとテストするだけで良い。
メソッド間の依存関係が0の場合、個別のメソッドが正しい結果を
返すなら、それをどんなに複雑に組み合わせても正しい結果を
返すだろう。


Statelessといっても、すべてスタティックメソッドにすれば良いという
ことではない。スタティックメソッドは、変更に弱くテストしにくい。


関連するクラス(インターフェース)だけをインスタンス変数に持つ
ようにし、ダイコンにDIしてもらうようにすれば良い。


くーす本の文体は、このようなシュール&ブラックな感じになります。
全部ほんとうのことですから！！！