どのクラスに処理を記述すべきか? 〜 Part2

SAStrutsアーキテクチャにおいて、それぞれの処理をどのクラスに
記述するのが良いかの検討を引き続き行う。


下図はブラッシュアップした現時点での判断チャート。
順を追って説明してみる。


ユーティリィティ的な処理か?

何を持ってユーティリィティ的な処理とみなすかは以外に難しい。


しかし、どのクラスに記述すべきかの見極め以前に、そもそも、
そのソースコードを書く必要があるかを疑ったほうがいい。


Apache CommonsやSeasar2のutilパッケージなど第三者
作成したユーティリィティクラスでかなりの代替が利くはず。
プログラマ全員がプロジェクトの最初の段階で、
役立つ3rdパーティのユーティリィティ情報を共有しておくべし。


あとは、ユーティリィティ的な処理かどうかの見極めに
自信がない人は、センスのよさそうに相談するのが良い。

画面周りの処理か?

画面周りのロジックの代表的なものは、
条件分岐によって画面遷移や画面部品等の振る舞いが変わるものと
とらえればイメージしやすいのではなかろうか。


さらに、この条件分岐のためのフラグ値を作成するための
メソッドまで落とし込めば分かり易いと思う。


注意すべきは、条件分岐の入力要素にEntityが絡むケース。
画面側とDB側の両方のクラスが絡むだけに、
『画面周りの処理である』と言い切るのに躊躇してしまいがち。
これについては、メソッドの引数にEntityそのものを渡すのではなく、
Entity内部のプロパティを渡すようにすることで、モヤモヤ感が晴れるはず。

複数のActionをまたがないか?

この判断は、アプリケーションの機能全体を見渡していないと
複数のActionをまたぐかどうかを判断しずらいので、
規模が大きいと結構難しいかもしれない。


これについては、アーキテクチャや個人の資質で対応するのは
限界があるとおもうので、マネジメントレベルでの
対策も検討しなければならないと思う。

特定のEntityへの処理記述に無理を感じるか?

これも難しい。コウモリ問題や同じクラスだが複数の別インスタンス
一括して扱うロジックなどを考慮すると、ロジックはEntityだけに
記述すれば良いものではないと思おう。


これはセンスと割り切らずに、いろいろな事例を検討して
明確な見極めポイントをもう少し模索する必要があるなぁ。