コンストラクターまたはセッターを介してデータを渡すことは機能しますが、コマンドの作成者はコマンドが必要とするデータを知る必要があります...
「コンテキスト」のアイデアは非常に優れており、しばらく前にそれを活用した (内部の) フレームワークに取り組んでいました。
コントローラー (ユーザーと対話する UI コンポーネント、ユーザー コマンドを解釈する CLI、着信パラメーターとセッション データを解釈するサーブレットなど) をセットアップして、使用可能なデータへの名前付きアクセスを提供すると、コマンドは必要なデータを直接要求できます。
このようなセットアップが可能にする分離が本当に好きです。階層化については、次のように考えてください。
User Interface (GUI controls, CLI, etc)
|
[syncs with/gets data]
V
Controller / Presentation Model
| ^
[executes] |
V |
Commands --------> [gets data by name]
|
[updates]
V
Domain Model
これを「正しく」行えば、同じコマンドとプレゼンテーション モデルをあらゆる種類のユーザー インターフェイスで使用できます。
これをさらに一歩進めると、上記の「コントローラー」はかなり一般的です。UI コントロールは、呼び出すコマンドの名前を知っていればよいだけです。UI コントロール (またはコントローラー) は、そのコマンドの作成方法や、そのコマンドが必要とするデータについての知識を持っている必要はありません。ここが本当の利点です。
たとえば、マップで実行するコマンドの名前を保持できます。コンポーネントが「トリガー」(通常は actionPerformed) されるたびに、コントローラーはコマンド名を検索し、それをインスタンス化し、execute を呼び出し、元に戻すスタック (使用している場合) にプッシュします。