Javaデザインパターンにおけるコマンドパターンの説明例

コマンド モードはコマンドのカプセル化です。コマンド モードのクラス図の基本構造を以下に紹介します。Java 設計モードのコマンド モードの知識に興味のある方は、一緒に見てください。

定義: リクエストを An にカプセル化します。このオブジェクトを使用すると、さまざまなリクエスト、キューまたはログリクエストでクライアントをパラメータ化し、コマンドの元に戻す機能とやり直し機能を提供できます。

タイプ: 動作パターン

クラス図:

コマンドパターンの構造

その名の通り、コマンドパターンはコマンドをカプセル化したものです。コマンド パターン クラス図:

• コマンド クラス: これは、実行する必要があるコマンドを宣言するクラスです。一般に、コマンドを実行するには、execute メソッドを外部に公開する必要があります。

• ConcreteCommand クラス: Command クラスの実装クラス。抽象クラスで宣言されたメソッドを実装します。

• クライアントクラス: 最後のクライアント呼び出しクラス。

上記の 3 つのクラスの機能は比較的理解しやすいと思いますが、Invoker クラスと Recevier クラスに注目してみましょう。

• Invoker クラス: Invoker、コマンドの呼び出しを担当します。

• Receiver クラス: コマンドの受信と実行を担当する受信者。いわゆるコマンドのカプセル化は、一連の操作をメソッドに記述するだけであり、クライアントはそれを呼び出す必要があります。必要なのは、Concretecommand クラスと Client クラスだけです。コマンドのカプセル化が完了したら、さらに柔軟性を高めるために、適切な抽象化を行うために別の Command クラスを追加できます。この呼び出し側と受信側の機能は何ですか。

実際、別の角度から考えることもできます。いくつかの操作を他の人が呼び出すためのコマンドとして単純にカプセル化した場合、どのようにしてそれをパターンと呼ぶことができるでしょうか?動作パターンとして、コマンド パターンはまず低結合を実現する必要があります。低結合により柔軟性が向上します。呼び出し側と受信側の 2 つの役割を追加する目的はまさにこの目的のためです。コマンド モードの一般的なコードは次のとおりです:

class Invoker { 
 private Command command; 
 public void setCommand(Command command) { 
  this.command = command; 
 } 
 public void action(){ 
  this.command.execute(); 
 } 
} 
abstract class Command { 
 public abstract void execute(); 
} 
class ConcreteCommand extends Command { 
 private Receiver receiver; 
 public ConcreteCommand(Receiver receiver){ 
  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(); 
  Command command = new ConcreteCommand(receiver); 
  //客户端直接执行具体命令方式（此方式与类图相符） 
  command.execute(); 
 
  //客户端通过调用者来执行命令 
  Invoker invoker = new Invoker(); 
  invoker.setCommand(command); 
  invoker.action(); 
 } 
}

コードを通して、呼び出し時の実行シーケンスは、最初に呼び出し側クラス、次にコマンド クラス、最後に受信側クラスであることがわかります。言い換えれば、コマンドの実行は 3 つのステップに分割され、その結合度はすべての操作をクラスにカプセル化するよりもはるかに低くなります。これがコマンド パターンの本質です。つまり、コマンドの呼び出し側と実行側が分離されます。双方とも、相手方がどのように行動するかを気にする必要はありません。

コマンド モードの長所と短所

まず第一に、コマンド モードは優れたカプセル化を備えています。クライアントにとって、機能が必要な場合は、各コマンドがカプセル化されており、対応するコマンドを呼び出す必要はありません。コマンドがどのように実行されるかを理解してください。たとえば、新しいファイルの作成、ファイルのコピー、ファイルの削除などの一連のファイル操作コマンドがあります。これら 3 つの操作がコマンド クラスにカプセル化されている場合、クライアントはこれら 3 つのコマンド クラスが存在することだけを知る必要があります。コマンド クラスにカプセル化されたロジックについては、クライアントは知る必要はありません。 第 2 に、コマンド モードは非常にスケーラブルです。コマンド モードでは、通常、受信クラスが最も基本的な操作をカプセル化し、新しいコマンドが追加されると、コマンド クラスがこれらの基本操作を再カプセル化します。コマンド クラスは通常、最初から開始されることはありません。呼び出されるレシーバー クラスと呼び出されるコマンド クラスの数は非常に多くなります。コードの再利用性は非常に優れています。たとえば、ファイル操作中にファイルを切り取るコマンドを追加する必要がある場合、ファイルのコピーとファイルの削除の 2 つのコマンドを組み合わせるだけで済み、非常に便利です。

最後に、コマンド モードの欠点について話しましょう。つまり、コマンドが多い場合、開発は頭の痛い問題になります。特に、コマンド モードを使用する場合、多くの単純なコマンドは、コマンドがどれほど単純であっても、それをカプセル化するためにコマンド クラスを作成する必要があります。

コマンドモードの適用可能なシナリオ

リクエスト/レスポンスモードの機能のほとんどでは、コマンドモードの定義にあるように、コマンドモードの方が次のような機能を実現するのに適しています。ログ記録と操作の取り消しが便利です。

概要

ボトム 場合によっては、これはすべての開発者にとって非常に複雑な問題です。需要の変化が予測されるため、システムの柔軟性と拡張性を確保するために特定の設計パターンが使用されることがありますが、逆に、コードを変更すると、予期せぬ需要が発生することがよくあります。使用されたデザイン パターンは逆効果で、プロジェクト チーム全体から不満の声が上がりました。プログラマーなら誰しもそのような例に遭遇したことがあると思います。したがって、アジャイル開発の原則に基づいて、プログラムを設計するときに、現在のニーズに応じて特定のパターンを使用せずにうまく解決できる場合は、デザインパターンの導入は難しくないため、導入すべきではありません。 . 、本当に使用する必要がある場合は、システムを改良してこの設計パターンを導入できます。コマンド モードを例に挙げます。一般的に、リクエストの応答操作はコマンド モードではなく、メソッドにカプセル化されます。この設計をパターンレベルに引き上げるかどうかは別途検討する必要があります。コマンドパターンを使用すると、呼び出し側と受信側の 2 つの役割が導入され、本来 1 か所にあったロジックが分散されてしまうためです。を 3 つのクラスに分けて設計する場合、コストに見合う価値があるかどうかを考慮する必要があります。

以上がJavaデザインパターンにおけるコマンドパターンの説明例の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。