>>537

>>535-536がどういうつもりで連呼しているかしらないが、
Delegateパターンは、本来煩雑になりがちな、SessionBean呼び出しまでの手順を、
フロントコントローラ（この場合、Actionクラス）の中に直書きしたくないので、
一連の手順を書きこんだstaticメソッドをまとめたクラスを、
ビジネスロジック層とフロントコントローラの間に咬ませよう、っていう程度のもの。
別にActionクラスの増加を抑える神の一撃というわけじゃない、はず。

ついでに言うと、Struts／フレームワーク開発の発想法から行くと、
各ボタンごとにばらばらのActionを割り当てるのは、別に間違いでない。
なぜなら、共通的な処理（前頁／次頁とか、上のメニューに戻るとか）以外一つのボタンは、
そのまま一つの処理に割りあってしまうケースも珍しくないから。
じゃあ、いっそのこと共通ルールで、一律１対１対応でやりましょう、というルールを敷くことだってある。
そういう開発方法を選んだプロジェクトでの開発なら、そういうものだと割り切って欲しい。