ゆうしゃくるみよ、それではレベルが低すぎるぞ。
Command パターンは、メッセージへの応答としてすぐに処理を実行するのではなく、「その処理を実行すること」を表すモデルです。Command のインスタンスは、実行可能なアルゴリズムと、生成時に決めたパラメーターを持ちます。
通常そのパブリックメソッドは、「主たる実行」を表すものが 1 つあるだけです。メソッドの名前は、execute だったり run だったり invoke だったり、あるいはバトルシステム内のアクションを意味する名前だったり、様々です。
もっと別の言い方をすれば、クロージャーやラムダと呼ばれる言語機能のことです。あるいは、関数型言語の言葉でいうところの、部分適用された関数を束縛する変数です。(C 言語の関数ポインタは、それ単体でパラメーターを持てないので少し違います)
なぜ「実行すること」なんて回りくどいインスタンスを作るのでしょうか。実行するときに呼べばいいんじゃ? それは、Command オブジェクトとして置いてあれば、じっさいに動かすタイミングを、実行計画を担うマネージャーに委ねることができるからです。もしくはキャンセルできるからです。
すばやさで順序が変わるゲームのバトルシステム以外にも、マルチスレッドのマネージャーだったり、複数のリクエストを受けるプリンタのジョブキュー(印刷ヘッドはひとつしかないので)のようなものだったり、逆に、一箇所で作った複数のジョブを分散実行させるシステムだったり... コンピューターシステムには、やることを決めるタイミングと、それを実行するタイミングをずらしたい場合がよくありますね。
Command はひとつのクラスからいくつも生成されます。いちど発行されると、基本的には、すべていつか実行され、実行が済んだらインスタンス破棄です。送ってしまったメールのパケットは、まだ相手に届いていないからといって、訂正することはできませんね。
ここが、基本 1 クラス 1 インスタンスでアルゴリズムを準備しておいて (Singleton っぽい)、選択したり入れ替えたりする Strategy パターンとの決定的な違いです。
クラスを単品で見てしまうと、Command は Strategy と区別がつきません。その実行可能なアルゴリズムをどうしたいのか、オブジェクトの使われ方から意味を読んで判断することがたいせつです。