オブジェクト指向設計でコマンド パターンが便利な理由がわかりません。
Switch
たとえば、クラスへの参照を持つコマンドを使用する代わりにLamp
、抽象クラスを作成してSwitchable
そのメソッドを呼び出すことはできませんか?
このようにして、インボーカーとレシーバーを分離しているので、レシーバー クラスごとに Command オブジェクトを作成する必要はありません。
オブジェクト指向設計でコマンド パターンが便利な理由がわかりません。
Switch
たとえば、クラスへの参照を持つコマンドを使用する代わりにLamp
、抽象クラスを作成してSwitchable
そのメソッドを呼び出すことはできませんか?
このようにして、インボーカーとレシーバーを分離しているので、レシーバー クラスごとに Command オブジェクトを作成する必要はありません。
インボーカーSwitchable
とレシーバーの間に抽象化を作成しますが、それらはまだ結合されています (インボーカーにはレシーバーへの参照が必要です)。Command パターンを使用すると、その分離を作成できます。インボーカーは中間コンポーネントに「このコマンドを実行したいのですが」と言い、中間コンポーネントはそのリクエストをレシーバーに動的に渡すことができます。
ps ...ウィキペディアからSwitchの例を引っ張ってきたと思います。これは、このパターンが有用である理由のかなり悪い例です。より良い例を見てみましょう。
次のようなリストを作成するとします。
アクションとレシーバーはすべて異なるため、それらすべてから切り離された抽象化が必要です。Command パターンは、元に戻す/やり直しなどをサポートしたい場合にも役立ちます。
次のように見てみましょう: クライアントがレシーバーに何らかのタスクを実行させたい場合、クライアントには 2 つのオプションがあります。
- 受信者に電話して、タスクを実行するよう伝えます。
- 受信者を知っている第三者に電話すると、第三者がメッセージを受信者に渡します。
最初のオプションは、シナリオを考えると、レストランで注文するウェイターがなく、シェフにあなたが望むものを伝えるためにシェフに行かなければならない場合に適しています。
または、リモコンをなくしてしまい、テレビに行ってボタンを手動で切り替える必要があるとします。
同期モードだけでなく、非同期モードでもコマンドを実行できる柔軟性を提供します。
You -> Switch -> Light
ここで、スイッチはあなたと光を切り離します。そのため、スイッチを使用してライトを簡単にオン/オフできます。これは、コマンド パターンを使用する際の使用 (便利) です。
あなた - コマンド実行者
スイッチ - コマンド管理者
コマンド - ライトのオン/オフ
- 実際の実装 者
コマンドパターンがない場合は、必要なときに手動でライトをホルダーに入れ、不要なときに取り外す必要があります。
各「コマンド」オブジェクトは、それ自体で何かを実行する方法を知っているライブ オブジェクトまたはタスクと考えてください。呼び出し元は、できるキューまたはリストです。
1) これらすべてのコマンド オブジェクトを保持し、
2) 好きな順序/方法でそれらを実行します。
このモデルはハンドラーに関して非常に柔軟ですね。呼び出し元は、タスクを実行するときに、任意のアルゴリズムをバッファリング、優先順位付け、または従うことができます。