Command Pattern を読みましたが、何かが足りないと思います。Command オブジェクトは、Receiver オブジェクトの詳細を抽象化するために存在します。ここでやめて、Command オブジェクトへの参照を保持し、適切なメソッドを適切なタイミングで実行できるように思えます。
では、なぜ Invoker が必要なのでしょうか? この追加の間接化にはどのような利点がありますか? レシーバーの詳細はコマンドの背後にすでに隠していますが、コマンドをクライアントからも隠す理由は何ですか?
そのように考えると、非常に複雑に見えますが、多くの場合、Receiver はオブジェクトである必要はまったくありません。(イベントとして) 実行される単なる関数に過ぎない場合があります。また、呼び出し側はクラスである必要はありません。コマンドをトリガーするのはそれだけです。これは、ボタンのイベント ハンドラーにすることもできます。
ウィキペディアでさえ、インボーカーとレシーバーの完全な個別のクラスを実際に実装する必要なく、このパターンが使用されるいくつかの例を要約しています。例として、GUI がコマンド オブジェクトを入力し、[完了] ボタンがそれをトリガーするウィザード ダイアログがあります。したがって、その GUI クラス (とにかく持っているもの) は、クライアントと呼び出し元の両方です。
私の知る限り、パターンの全体的なポイントは、ある種のコマンドプロデューサーとある種のコマンドコンシューマーを持ち、プロデューサーがコンシューマーを変更せずにコマンドを作成または変更できるようにすることです。
このパターンでは、プロデューサーを「クライアント」、コンシューマーを「呼び出し元」と呼びます。
これはOOコールバックです。
では、なぜ呼び出し側が必要なのか
ウィキペディアのすべての例からわかる限り、呼び出し元には明確な形式がありません。これは、抽象コマンドを受け入れる単なるコードです。
ここで停止して、コマンドオブジェクトへの参照を保持できるように思えます
コマンドを呼び出して抽象コマンドへの参照を受け入れるか保持することがコードで意味をなす場合は、既に呼び出し元を実装しています。
1ビットのコードがプロデューサーとコンシューマーの両方である場合、コマンドパターンは無意味です。抽象コマンドを呼び出したいものに渡す場合にのみ価値があります。