Command パターン
コマンドが共有されたリソースにタスクとして書き込まれ、多数のスレッドで並列に実行される(おそらくはリモートのマシンで)。この方式はマスター/ワーカーパターンと呼ばれていることも多い。
このパターンがもつ利点の1つはリクエスト依頼処理と実装処理の分離(疎結合)である。
例えばクリックでリクエストを実行できるUIフレームワークを開発するとする。ボタンのクリック機能とリクエストの実行はフレームワークの責務だが、リクエストで具体的に何が起こるかはアプリケーションの責務である。すなわちUIフレームワーク側はクリックに応じてリクエストを発行するが、リクエストに対してどのような処理がおこなわれるのか、そもそもリクエストの受け手が誰なのか知らない。ここでボタンの生成時にCommandを受け入れるとする。UIフレームワーク側はCommandがどんな処理を内包しているかは(カプセル化されているので)わからないが、.Execute()を実行すればリクエストが実行されることは知っている。このinterfaceを介した契約により、クリック時にcommand.Execute()するだけでクリックに応答したリクエストを実行できる。このようにCommandパターンはCommandの実行と実装を疎結合にできる。言い換えれば、CommandパターンはCommandオブジェクトのDIによる処理と実行の分離(関心の分離)である。これは手続き型プログラミングにおけるcallbackに相当する。
このパターンがもつもう1つの利点はCommandが独立したオブジェクトである点である。未実行のCommandオブジェクトを配列にいれればキューイングが可能であり、それに応じた非同期処理・スケジューリングが可能になり、実行済みのCommandをキューイングすれば履歴保存とロギング・Undoなどが可能になる。