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