Commandパターン

概要

Commandパターンは、Gang of Four（GoF）によって提唱された23種類のデザインパターンの一つであり、振る舞いに関するパターン（Behavioral Pattern）に分類される。このパターンの核心は、システム内で発生するあらゆる命令やリクエストを、実行に必要な情報すべてを保持した「コマンドオブジェクト」として扱う点にある。これにより、命令そのものをデータとして操作可能にし、システムの柔軟性と拡張性を劇的に向上させる。一般的なメソッド呼び出しが、その場で処理を完了させるのに対し、コマンドオブジェクトは「実行する」という行為を遅延させたり、外部に委譲したりすることを可能にする。

ソフトウェア設計において、命令をオブジェクト化するというアプローチは、プログラムの制御フローをデータとして扱い、命令発行者（Invoker）が実際の処理実行者（Receiver）の詳細を知る必要がないように設計することを目的としている。

構造と役割

Commandパターンを実装する際には、通常、以下の四つの主要な構成要素が登場する。これらの要素が連携することで、発行者と実行者が完全に分離された命令処理システムが構築される。

1. Command (コマンド): 命令をカプセル化したインターフェースまたは抽象クラスである。通常、すべてのコマンドが共通して実装すべき単一の実行メソッド（例: execute()）を定義する。
2. ConcreteCommand (具象コマンド): 特定の命令（例えば、「ファイルを開く」「テキストを貼り付ける」など）と、その命令の実行に必要なレシーバのインスタンスを保持する。execute() メソッドが呼び出された際、具象コマンドはレシーバの適切なメソッドを呼び出すことで、実際の処理を実行する。具象コマンドは、レシーバのどの操作を、どの引数で呼び出すかを知っている。
3. Receiver (レシーバ): 実際の業務ロジックや操作を行うオブジェクトである。コマンドオブジェクトは、レシーバの特定の操作を呼び出すことによってタスクを実行する。レシーバは、コマンドパターンの外から見れば通常の業務ロジックであり、自身の操作をどのように実行するかについてはコマンド構造に依存しない。
4. Invoker (呼び出し側): コマンドオブジェクトを受け取り、その実行を要求する役割を持つ。インヴォーカーは、実行すべきコマンドオブジェクトを保持し、適切なタイミングでコマンドの execute() メソッドを呼び出す。インヴォーカーは、それがどのレシーバに対するどのような具体的な操作であるかを知る必要がなく、単にコマンドインターフェースに対する操作として処理を行う。この強力な抽象化により、インヴォーカーは多種多様な命令を統一的なインターフェースを通じて扱うことができるようになる。

具体的な使用例・シーン

Commandパターンが最も効果を発揮するのは、命令そのものを管理・操作する必要がある高度な制御シーンである。

1. Undo/Redo機能の実装

Commandパターンの最も代表的な適用例は、操作の取り消し（Undo）および再実行（Redo）機能の実装である。エディタやCADソフトウェアなど、ユーザー操作履歴の管理が必須となるアプリケーションで利用される。

実行された全てのコマンドオブジェクトをスタック（Undoスタック）に順序通り保存する。このとき、具象コマンドクラスには、実行操作と逆の操作を行うための unexecute() メソッドも実装される必要がある。ユーザーがUndoを要求すると、スタックの先頭からコマンドを取り出し、その unexecute() を呼び出すことで、システムの状態を元に戻す。

さらに、Undoされたコマンドを別のスタック（Redoスタック）に移すことで、Redo機能を実装できる。この機能は、コマンドオブジェクトが実行に必要な情報だけでなく、取り消しに必要な情報（実行前の状態や逆操作のロジック）をもカプセル化しているからこそ実現可能となる。

2. トランザクション管理とロギング

データベース操作などのトランザクション処理において、一連の命令を一つのユニットとして扱い、すべて成功した場合にコミット、一つでも失敗した場合にロールバックする制御を行う際に有効である。

また、システム監査やデバッグ、クラッシュリカバリのために、実行された全ての操作をコマンドオブジェクトとして永続的なログ（ジャーナル）に記録することが可能となる。このログを再生（リプレイ）することで、システムの状態を特定時点に復元したり、障害発生時の状況を再現したりすることができる。

3. リモート処理とキューイング

Commandパターンは、命令の実行を遅延させたり、非同期で行ったりする処理にも適している。例えば、大量のタスクや時間のかかる処理をバックグラウンドで行いたい場合、それらのタスクをコマンドオブジェクトとしてキューに入れておく。ワーカープロセスはキューからコマンドを取り出し、その execute() メソッドを呼び出すことで処理を実行する。これにより、クライアント側はタスクの完了を待たずに次の操作に進むことができる。また、コマンドオブジェクトをネットワーク越しにシリアライズして転送し、リモートサーバーで実行させるリモートプロシージャコール（RPC）の実装基盤としても利用される。

メリット・デメリット (特徴)

メリット

Commandパターンの最大の利点は、命令の発行者（Invoker）と実際の処理実行者（Receiver）の間に高い疎結合をもたらすことである。インヴォーカーはコマンドインターフェースのみに依存するため、新しいコマンドの追加やレシーバの実装変更が、既存のインヴォーカーのコードに影響を与えることがない。

また、命令をオブジェクトとして扱うことで、命令の操作（キューイング、ロギング、履歴管理、取り消し）が容易になり、Undo/Redo機能やマクロ機能といった高度な制御機能の実装が飛躍的に簡単になる。この機能性の向上は、システム全体の堅牢性、柔軟性、再利用性を高めることに直結する。

デメリット

命令のたびに独立した具象コマンドクラスを定義する必要があるため、単純な操作であってもクラス数が大幅に増加し、全体としてコードベースが肥大化する傾向がある。特に、多くの種類の命令が存在する場合、クラス定義の数が設計上のオーバーヘッドとなる。

また、コマンドオブジェクトはレシーバのインスタンスと実行に必要な引数を保持しなければならないため、シンプルなメソッド呼び出しと比較してメモリ使用量が増加する可能性がある。アプリケーションの規模が非常に小さい場合や、Undoなどの高度な機能が不要な場合には、このパターンの導入は過剰な設計となり、かえって保守性を低下させる可能性がある。

関連する概念

Commandパターンは、特定の目的を達成するために他のデザインパターンとしばしば連携して利用される。

Strategyパターンとの関係

CommandパターンとStrategyパターンは、どちらも「処理をオブジェクトとしてカプセル化する」という点で構造的に非常に類似している。しかし、その目的は異なる。

Commandパターンは、命令そのもの（実行すべき操作と実行対象）をオブジェクト化し、命令のライフサイクル管理（遅延実行、キューイング、履歴管理）に主眼を置く。一方、Strategyパターンは、アルゴリズム（実行方法）をオブジェクト化し、実行時にアルゴリズムを交換可能にすることに主眼を置く。Strategyパターンでカプセル化されたアルゴリズムは通常、実行後に破棄されるのに対し、CommandオブジェクトはUndo/Redoのために永続化されることが多い。

Mementoパターンとの関係

CommandパターンでUndo機能を実装する際、実行前の状態を正確に復元するために、Mementoパターン（状態を保存するパターン）が組み合わせて利用されることが多い。

Commandオブジェクトは、execute() を実行する直前に、処理対象であるレシーバの重要な状態をMementoオブジェクトとして保存しておく。そして、unexecute() が呼び出された際、保存しておいたMementoオブジェクトを利用してレシーバの状態を復元する。これにより、コマンドが具体的なレシーバの詳細な内部状態に依存することなく、安全かつ確実に「元に戻す」操作を実現できる。

Compositeパターンとの関係

複数のコマンドを一つのコマンドとして扱う場合、Compositeパターン（複合パターン）が適用される。例えば、ユーザーが複数の操作を一括で行う「マクロ」機能を実装する場合、複数の ConcreteCommand オブジェクトを格納した MacroCommand クラスを定義する。MacroCommand もまた Command インターフェースを実装しているため、インヴォーカーは単一のコマンドとしてマクロを実行することができる。

由来・語源

Commandパターンは、その名の通り「命令（Command）」を抽象化し、オブジェクトとして表現することに由来する。GoFの著書『Design Patterns: Elements of Reusable Object-Oriented Software』において体系化された。初期のオブジェクト指向設計において、ユーザーインターフェース（GUI）やエディタアプリケーションのように、ユーザーの操作を記録し、それを後で取り消し（Undo）たり、マクロとして再利用したりする機能の実装が求められた際に、このパターンが特に有効であると認識された。

命令をオブジェクトとして切り離すことにより、命令の呼び出しと実行を時間的にも空間的にも分離できる。これは、機能の追加や変更が頻繁に行われる大規模なシステムにおいて、コードのメンテナンス性を維持するために不可欠な設計思想である。

使用例

(記述募集中)

関連用語

• (なし)