commandという単語は「命令」という意味です。「コマンド」と書くとUNIX、Linuxのコンソールで入力するコマンドを連想される方も多いかと思います。

Commandパターンはその名の通り「命令」そのものをクラスとして表すパターンです。
ほとんどのアプリケーションでは、利用者はアプリケーションに何らかの要求を出し、アプリケーションは要求を受け取って処理を実行しています。先に出てきたLinuxなどのコマンドもその1つですし、WindowsのGUIでの操作も含まれます。

たとえば、ファイルを圧縮する場合を考えてみます。Windowsの場合、圧縮ソフトにファイルをドラッグアンドドロップするといった操作になりますし、Linuxなどのコンソールから実行する場合、圧縮コマンドにファイル名を指定して実行するでしょう。
この時、利用者はソフトウェアやコマンドを通じて「圧縮する」という要求を出し、対象のファイルがその要求を受け取っている、と考えることができます。また、ファイルに別の操作をおこなう、つまり別な要求を出す場合は、「処理をおこなうソフトやコマンド」を差し替えたものと考えられるでしょう。

ここで、「要求を送る」ということは、オブジェクト指向プログラミングの場合、オブジェクトのメソッドを呼び出すということになりますが、要求が複雑になったり要求の種類が多くなると、その実装にも限界が出てきますし保守性も悪くなってしまいます。
そこで、「要求を送る」「要求を受け取る」という考えに基づいて、「要求」自身をクラスとしてまとめてしまうと、具体的な要求を1つのオブジェクトとして扱うことができ、複雑な要求の場合でも容易に扱えるようになります。また、送る要求オブジェクトを変えることで、異なる要求を実現こともできそうです。

Commandパターンの定義は、
要求をオブジェクトとしてカプセル化することによって、 様々な要求または要求からなるキューやログによりクライアントを パラメータ化する。そして、取り消し可能な操作をサポートする。
です。

Commandパターンでは、異なる種類の要求に対する処理を同じAPIを持つクラスとして実装します。その結果、処理クラスのインスタンスを切り替えるだけで、様々な要求に対する処理を実行できるようなります。また、Commandパターンを適用すると、新しい要求に対する処理クラスを実装するだけで、既存のクラスを修正することなく対応可能になります。

ということで、「要求」そのものをクラスとして表し、「要求を送る側」と「要求を受け取る側」を分離するCommandパターンについてでした。