✅ 本記事のねらい

Struts2におけるアクションクラスの設計は、単なるリクエストの受け口にとどまらず、
「アプリ全体の保守性・拡張性・わかりやすさ」を左右する重要な設計ポイントです。

本記事では、以下の3つのアクションクラス設計スタイルを比較しながら、
それぞれの特徴・メリット・デメリット・適用判断基準について整理します。

はじめに：アクションクラス設計がUXと保守性を左右する
スタイル①：1クラス1ユースケース型（単機能Action）
スタイル②：1クラス多メソッド型（機能集約Action）
スタイル③：共通BaseAction型（抽象化による責務分離）
【比較表】3スタイルの特徴と選定基準まとめ
おわりに：設計スタイルに「正解」はない。文脈で選ぼう

1. はじめに：アクションクラス設計がUXと保守性を左右する

Struts2のアクションクラスは、ユーザーからの入力（リクエスト）を受けて処理を分岐し、
結果をビューに返すという重要な役割を担います。

ユーザー操作 → アクション層 → サービス層 → DB → 結果を返却（JSP等）

このアクションクラスの設計方針を誤ると…

ファイル構成が散らかる
機能の責任が曖昧になる
画面遷移がわかりにくくなる
コードの読みやすさ・変更しやすさが損なわれる

といった問題を引き起こします。

逆に、適切な設計スタイルを選べば、UX（ユーザー体験）と開発効率が大きく向上します。

2. スタイル①：1クラス1ユースケース型（単機能Action）

🔸 特徴

1画面、1ユースケースに対して1つのActionクラス
それぞれが独立した単機能を担う

✅ メリット

コードが短く、読みやすい
処理の責務が明確で、テストもしやすい
ユースケース単位でファイルが完結

⚠ デメリット

Actionクラス数が多くなりやすい
処理の共通化が難しくなる（重複コードの温床に）

🧩 向いているケース

CRUD処理が中心の業務システム
開発メンバーのスキルに差があるチーム

3. スタイル②：1クラス多メソッド型（機能集約Action）

🔸 特徴

1つのActionクラスに複数のメソッドを持たせ、複数機能を担当
method属性などで切り替え

<action name="user" class="UserAction" method="register">
<action name="user" class="UserAction" method="delete">

✅ メリット

ファイル数を抑えられる
関連機能を1ファイルに集約できて見通しがよい

⚠ デメリット

クラスが肥大化しやすく、責任が曖昧になりやすい
テスト時にMockが複雑になることも

🧩 向いているケース

1画面に複数機能がある複合画面（一覧・検索・削除など）
担当者が熟練しており責務分担を意識して書けるチーム

4. スタイル③：共通BaseAction型（抽象化による責務分離）

🔸 特徴

各ActionクラスはBaseActionを継承
セッション・リクエスト・共通メッセージ処理などを集約

public class BaseAction extends ActionSupport implements SessionAware {
    protected Map<String, Object> session;
    public void setSession(Map<String, Object> session) {
        this.session = session;
    }
}

✅ メリット

重複処理（例：ログインユーザー取得）が一元化
共通機能の変更が1箇所で済む

⚠ デメリット

継承構造が複雑化しやすい
過剰に共通化すると副作用が起きる

🧩 向いているケース

ログイン/権限/画面フローが複雑な中〜大規模アプリ
チーム開発で共通ルールが統一されている環境

5. 【比較表】3スタイルの特徴と選定基準まとめ

スタイル	保守性	可読性	拡張性	向いているケース
単機能型	◎	◎	△	CRUD中心、シンプルな業務画面
多機能集約型	△	◯	◯	関連処理が密接な複数機能の統合画面
BaseAction継承型	◯	△	◎	中～大規模、権限/セッション処理が必要なシステム

6. おわりに：設計スタイルに「正解」はない。文脈で選ぼう

アクションクラスの設計スタイルには「これが正解！」というものは存在しません。

選定時に大事なのは、「何を重視したいか（読みやすさ／共通化／今後の拡張）」と
「チーム体制やアプリの成長段階」に応じて適切なバランスを取ることです。

✅ 迷ったときは…

まずは単機能で作る → 後でBaseActionなどで共通化

機能単位で整理してから、共通処理や粒度を揃える

拡張を意識した「設計コメント」や「Javadoc」も後の保守に効きます！

🔜 次回予告：Vol.11.2.3「戻り先制御と画面遷移の設計パターン」

input / success / error / cancel をどう設計に活かすか？
複数遷移先を持つActionの設計テクニックとは？
ユーザーの操作意図に沿った自然な画面遷移設計へ！

ご感想・ご質問・実プロジェクトでの工夫など、ぜひコメントでお寄せください🙏
次回もよろしくお願いいたします！

✨ シリーズまとめ（Vol.11.2.xx アクション層設計）

🧭 関連記事（Vol.11.xxxシリーズ）

連番	タイトル	内容分類
Vol.11.0	Struts2が提供してくれる便利機能まとめ9選	導入＆概要
Vol.11.1	自動注入とステートレスActionの仕組み	フレームワーク内部理解
Vol.11.2	UX改善に効く！アクション層設計と入力制御の極意（プロローグ）	UX設計・アクション層総論
Vol.11.2.1	【実践編】Struts2アクション層の役割と設計パターン（Command型 / UIアクション分離など）	アクション設計パターン
Vol.11.2.3	【設計ノウハウ】多画面遷移時のパラメータ受け渡し・保持戦略（セッション vs hidden vs URL）	パラメータ多重管理
Vol.11.2.4	【実践ガイド】ユーザー操作を考慮したアクション遷移設計（リダイレクト vs フォワードの使い分け）	UX遷移設計／Result制御
Vol.11.2.5	【トラブル防止】アクション層の共通処理とメンテナブルなBaseAction設計	アクション共通化／保守性
Vol.11.3	Struts2の defaultStack とは？Interceptorの中身を詳しく追ってみる	Interceptor
Vol.11.3.2	🔧 Vol.11.3.2 独自Interceptorの作り方と使い所 Struts2のカスタマイズを“実践で使えるレベル”に一歩進めよう	Interceptor
Vol.11.4	入門者のための「パラメータ自動バインディング」完全理解ガイド	自動バインディング
Vol.Vol.11.4.1	入門者のための自動バインディング実践パターン集	自動バインディング
Vol.11.5	Struts2の構成理解が“実務レベル”へと進化する決定版	設定ファイル構造
Vol.11.5.1	Struts2の“画面遷移の全体像”を理解するためのマイルストーン記事	設定ファイル構造
Vol.11.6	ActionSupport の便利メソッドと国際化対応	ユーティリティ / i18n
Vol.11.7	validate() / input 戦略とUX設計	開発スタイルの違い
Vol.11.8	アノテーションベースの設定 vs XML定義の比較	開発スタイルの違い
Vol.11.9	バリデーション完全解説（XML / アノテーション）	バリデーション（※Vol.8補完）
Vol.11.10	Struts2の「OGNL」ってなに？しくみと使い方をやさしく解説	式言語OGNL解説
Vol.11.11	ModelDriven インターフェースの使いどころと注意点	Model駆動開発
Vol.11.12	SessionAware と RequestAware でセッション/リクエスト管理	セッション管理
Vol.11.13	Resultタイプ完全解説（dispatcher / redirect / stream など）	遷移パターン理解
Vol.11.14	Vol.11.14 ValueStackの中身を理解する – 画面とActionの橋渡し役	Action
Vol.11.15	Interceptorチェーンを自作してみよう（ログ / 認証フィルタ）	Interceptor
Vol.11.16	エラー処理と例外ハンドリングの実践パターン	ハンドリング設計
Vol.11.17	Struts2でファイルアップロード機能を実装する方法	実装系Tips
Vol.11.18	非同期通信（AJAX）とStruts2の連携方法	フロント連携編
Vol.11.19	セキュリティ対策（CSRF, XSS, パラメータ偽装）	セキュリティ対策
Vol.11.20	複数フォームを安全に扱う！セッション管理と動的フォームの考え方	セッション管理
Vol.11.21	Struts2でJSONを返す！REST API連携と非同期通信の基本設計	セッション管理
Vol.11.22	本番環境構成とセキュリティ設計（Apache+Tomcat+Struts2連携）	外部公開