design-patterns - コマンドパターンはアダプター以上ですか?

Question

GoF Command Pattern UML によると、 ConcreteCommandはRecieverを共通のCommand (可能性がある) インターフェイスに適応させるだけのように思えます。私はおそらく金槌に打たれているので、どこが違うのか、何が間違っていたのかを説明してください。

Answer 1

これらのパターンの多くは非常によく似ており、意図はパターン定義を理解するのに役立ちます。これらのパターンに関する私の（おそらく不完全な）知識は次のとおりです。

コマンドパターンは、呼び出し元を操作から分離します。

コマンドは、特定の要求、受信者、または呼び出し元に依存しない存続期間を持つ場合があります。これは、別個のファーストクラスのエンティティです。これにより、異なる時間にコマンドをキューに入れて実行する機能が可能になり、おそらくログ記録のために、コマンドの実行を記録/記憶することができます。

例として、UIコマンドの実装、元に戻す、やり直し機能、またはトランザクション管理を整理するために使用できます。

アダプタパターンは、オブジェクトを別のオブジェクトの使用法に適合させるために使用されます。

別のオブジェクトで動作するオブジェクト（ConcreteCommandがReceiverに対して何かを実行する）を、Adapterがプロキシのように機能してAdapteeが他の共同作業者と連携できるようにする「Adaptor」パターンの実装と混同しないでください。

Answer 2

両者は本質的に異なります。理由を説明しましょう：

コマンドパターンを使わずに飛行機で移動することはできません！

あなたが頻繁に旅行する場合、クライアントとして気になるのは、現在地から別の場所へ移動することだけです。パイロットがどのように飛行機を飛ばすか、どの航空会社が利用できるかは気にしません..それを実際に予測することはできません. 必要なのは、空港に行き、目的地まで連れて行ってくれるように伝えることだけです。しかし、そんなことをしたら、空港当局へのあなたの命令は笑われるでしょう! チケットであるコマンドオブジェクトを提供する必要があります。どの航空会社やどの飛行機の種類でも構いませんが、飛行する準備ができたら、チケット コマンド オブジェクトを提供する必要があります。空港職員であるインボーカーは、コマンド (チケット) を確認して、それが偽物である場合は元に戻し、間違いがあった場合はやり直すことができるようにする必要があります (予約プロセス全体を実行する必要はありません)。 . 要するに 、彼らは、あなたのコマンドを呼び出すか実行するかを決定する前に、あなたのコマンド (チケット) を完全に制御したいと考えています。コマンド (チケット) には既に受信者 (航空会社) の情報が含まれているため、空港職員は最初からチケットの処理を開始することさえできません。

空港当局は、彼らが取り組んでいるたくさんのチケットを持っている可能性さえあります. 彼らは私のチケットを遅らせて、私の後に来た誰かを通過させることを選択するかもしれません（私の前に別の人のチケットを呼び出します）

アダプターパターンを使用しないと、通常のトレードはできません！

少し前までは、取引の主な手段はバッターでした。私のラップトップが必要な場合は、デスクトップとテレビをください。問題は、あなたが私が欲しいものを持っていない可能性があるため、取引できないことでした. 解決策はアダプターパターンでした。互換性のないインターフェース（ウォンツ）があるため、取引できませんでした。だからお金が発明された。私のラップトップが必要な場合は、アダプターを介してポーンしてお金を稼いでください。うん！どうしてもお金が欲しい。ほとんどすべてが Money (または Dollars がインスタンスである IMoney) と呼ばれる抽象クラスを実装しています。あなたは？Command パターンとは対照的に、money には受信者に関する情報がありません。お金が私を受信者とするコマンド オブジェクトであることを願っています。それはとてもクールになります。しかし、いいえ！チケットは呼び出し、取り消し、やり直しなどを行うことができますが、お金は常に受け入れられます。あなたが私に何かをくれたら、私がすることは1つです。それを受け入れてください。

Answer 3

adapter is-a または has-a adaptee のいずれかです。具体的なコマンドにはレシーバーがあります。したがって、矢印は反対方向に進みます。