定義：リクエストをオブジェクトにカプセル化し、さまざまなリクエスト、キューリクエスト、または要求ログを記録し、コマンドの取り消しと回復機能を提供してクライアントをパラメーター化できるようにします。
タイプ：行動パターン
クラス図：
コマンドモードの構造
名前が示すように、コマンドモードはコマンドのカプセル化です。まず、コマンドモードクラスの図の基本構造を見てみましょう。
コマンドクラス：実行する必要があるコマンドを宣言する抽象クラスです。一般的に言えば、コマンドを実行するには、実行方法を一般に公開する必要があります。
ConcreTeCommandクラス：コマンドクラスの実装クラスは、抽象クラスで宣言された方法を実装します。
クライアントクラス：最終クライアント呼び出しクラス。
上記の3つのクラスの機能は理解しやすいはずです。招待者のクラスとrecevierクラスに焦点を当てましょう。
招待者クラス：発信者はコマンドを呼び出す責任があります。
受信機クラス：レシーバーは、コマンドを受信および実行する責任があります。
率直に言って、コマンドのいわゆるカプセル化は、一連の操作をメソッドに書き込み、クライアントによって呼び出されることに過ぎません。クラス図に反映されています。コマンドのカプセル化を完了するには、ConcreTeCommandクラスとクライアントクラスのみが必要です。さらに進んでも、柔軟性を高めるために、適切な抽象化のためにコマンドクラスを追加できます。この発信者と受信機の機能は何ですか？
実際、別の観点から考えることができます。他の人が呼び出すコマンドとしていくつかの操作を単にカプセル化する場合、どのようにパターンと呼ばれることができますか？行動モデルとして、コマンドモードは最初に低カップリングを達成する必要があります。カップリングの程度が低い場合にのみ、柔軟性が向上します。発信者と受信者の役割を追加する目的は、これに正確に行われます。
例：
テレビの操作のシミュレーションには、パワーオン、シャットダウン、および変更コマンドが含まれます。コードは次のとおりです
//コマンドパブリックインターフェイスコマンドを実行するためのインターフェイス{void execute（）; } //コマンドレシーバー受信機パブリッククラスTV {public int currentchannel = 0; public void turnon（）{system.out.println（ "Televisinoがオンになっています。"）; } public void turnoff（）{system.out.println（ "テレビはオフです。"）; } public void changechannel（int channel）{this.currentchannel = channel; System.out.println（ "Now TVチャンネルIS" +チャンネル）; }} //シャットダウンコマンドConcreTeCommand Public Class Commandon Commant Command {private tv mytv; Public Commandon（TV TV）{mytv = TV; } public void execute（）{mytv.turnon（）; }} //シャットダウンコマンドConcreTeCommand Public Class CommandOff Command {private tv mytv; Public CommandOff（TV TV）{mytv = TV; } public void execute（）{mytv.turnoff（）; }} //チャネルスイッチングコマンドConcreTeCommand public classCommandChange Commant Command {private TV mytv;プライベートINTチャンネル。 Public CommandChange（TV TV、int Channel）{mytv = TV; this.channel = channel; } public void execute（）{mytv.ChangeChannel（Channel）; }} //リモートコントロールの招待者パブリッククラスコントロール{private command oncommand、offcommand、changeChannelと見なすことができます。パブリックコントロール（コマンドオン、コマンドオフ、コマンドチャネル）{oncommand = on; offcommand = off; changechannel = channel; } public void turnon（）{oncommand.execute（）; } public void turnoff（）{offcommand.execute（）; } public void changechannel（）{changechannel.execute（）; }} //テストクラスクライアントパブリッククラスクライアント{public static void main（string [] args）{//コマンド受信者レシーバーTV = new TV（）; // Power-on Command ConcreTeCommond Commandon on = new Commandon（mytv）; //シャットダウンコマンドConcreTeCommond CommandOff off = new CommandOff（MYTV）; // Channel SwitchingコマンドConcreTeCommond CommandChange Channel = new CommandChange（mytv、2）; //コマンドコントロールオブジェクトInvoker Control = new Control（on、off、channel）; // Power-on Control.Turnon（）; // Channel Control.ChangeChannel（）を切り替えます。 // control.turnoff（）; }}実行結果
Televisinoがオンになっています。テレビチャンネルは2です。テレビがオフになっています。
コマンドモードの利点と短所
まず、コマンドモードは非常にカプセル化されています。各コマンドはカプセル化されており、クライアントの場合、コマンドがどのように実行されるかを知らずに、対応するコマンドが必要と同じくらい呼び出されます。たとえば、ファイル操作コマンドのセットがあります。新しいファイルを作成し、ファイルをコピーし、ファイルを削除します。これらの3つの操作がコマンドクラスにカプセル化されている場合、クライアントはこれら3つのコマンドクラスがあることを知る必要があります。コマンドクラスにカプセル化されたロジックについては、クライアントを知る必要はありません。
第二に、コマンドモードには優れたスケーラビリティがあります。コマンドモードでは、受信機クラスでの操作の最も基本的なカプセル化、およびこれらの基本操作のコマンドクラスのセカンダリカプセル化。新しいコマンドを追加する場合、コマンドクラスの書き込みは一般にゼロからではありません。通話用のレシーバークラスが多数あり、コール用のコマンドクラスも多数あり、コードは非常に再利用可能です。たとえば、ファイルの操作では、ファイルをカットするためにコマンドを追加する必要があります。ファイルをコピーしてファイルを削除するという2つのコマンドを組み合わせただけで、非常に便利です。
最後に、コマンドモードの欠点、つまり多くのコマンドがある場合、開発するのは頭痛の種になります。特に、多くの単純なコマンドは、実装するコードの数行にすぎません。コマンドモードを使用する場合、コマンドがどれほど簡単かを心配する必要はありません。コマンドクラスを記述してカプセル化する必要があります。
コマンドモードに適用されるシナリオ
ほとんどのリクエスト応答モード機能では、コマンドモードを使用する方が適しています。コマンドモードの定義が示すように、コマンドモードは、操作のロギングや元に戻すなどの機能を実装するのに便利です。
要約します
機会にモードを使用するかどうかは、すべての開発者にとって非常にもつれた質問です。要件のいくつかの変更が予測されるため、システムの柔軟性とスケーラビリティに特定の設計パターンが使用される場合がありますが、この予見可能な要件は使用されません。それどころか、多くの予測不可能な要件が生じ、その結果、コードを変更する際に反対の役割を果たすデザインパターンが使用されているため、プロジェクトチーム全体が不満を述べました。すべてのプログラマーがそのような例に遭遇したと思います。したがって、アジャイル開発の原則に基づいて、プログラムを設計するとき、現在のニーズに応じて特定のパターンを使用せずにそれらをうまく解決できる場合、デザインパターンを導入することは難しくないため、導入すべきではありません。それを使用してこのデザインパターンを導入するために本当に必要なときに、システムでそれを行うことができます。
例としてコマンドモードを取ります。私たちの開発では、リクエスト応答モード関数が非常に一般的です。一般的に言えば、リクエストへの応答操作をメソッドにカプセル化します。このカプセル化されたメソッドは、コマンドと呼ばれますが、コマンドモードではありません。コマンドモードを使用する場合、発信者と受信機の2つの役割を導入する必要があるため、この設計をパターンの高さまで引き上げる必要があるかどうかを個別に考慮する必要があります。もともと1つの場所に配置されていたロジックは、3つのカテゴリに散在しています。設計するときは、このコストが価値があるかどうかを考慮する必要があります。