命令模式比適配器多嗎？

Question

根據GoF的命令模式UML在我看來，像的ConcreteCommand只是適應Reciever共同命令（可能是）接口。我可能會遇到golden hammer，所以請解釋區別在哪裏或者我錯了什麼。

Answer 1

很多這些模式看起來非常相似，意圖確實有助於理解模式定義。這裏是我對這些模式（可能不完整）的瞭解：

命令模式將操作調用者分離出來。

命令可能有一個獨立於特定請求，接收者或調用者的生命週期 - 它是一個獨立的頭等實體。它允許在不同的時間進行排隊和執行命令，並允許記錄/記錄命令執行，也許可以用於記錄。

它可以用來組織UI命令實現，撤銷或重做功能或事務管理作爲示例。

適配器模式用於使對象適應其他使用方式。

我不會將一個運行在另一個對象上的對象（ConcreteCommand對Receiver做某些事情）與Adapter模式的實現相混淆，其中Adapter實際上就像一個代理，允許Adaptee與其他協作者一起工作。

Answer 2

適配器要麼是-a或具有-一個適配者。具體的命令有一個接收器。所以箭頭朝向另一個方向。

Answer 3

兩者本質上不同。讓我解釋一下爲什麼：

不能使用命令模式，不能使用飛機從一個地方飛到另一個地方！

如果你是一個經常旅行的人，作爲一個客戶你所關心的就是從你從哪裏旅行到另一個。你不在乎飛行員如何駕駛飛機或哪家航空公司可以使用..你無法真正預測到這一點。所有你想要的是去空港，並告訴他們帶你到目的地。但是如果你這樣做，你對機場當局的命令將會被嘲笑！他們需要你提供一個命令對象，這是你的票據。就像你不關心哪一家航空公司或哪一架飛機類型一樣，當你準備好飛行時，你需要提供一個票據命令對象。調用者是機場官員需要檢查你的命令（票），以便他們可以驗證它，如果它是假的就撤消它，如果他們犯了錯誤就重做（無需你必須經過整個預訂過程） 。總之，他們希望在決定是否調用或執行您的命令（讓航空公司（接收方）執行（讓您乘飛機並帶您到達目的地））之前完全控制您的命令（票證）。請注意，你的命令（你的機票）已經有了接收機（航空公司）的信息，否則機場官員甚至不會開始處理你的機票。

機場當局甚至可能有一堆他們正在開發的票。他們可能會選擇延遲我的機票並讓我之後經過的人（在我之前調用另一個人的機票）

如果不使用適配器模式，您不能交易！

過去一段時間，主要的貿易手段是通過麪糊：如果你想要我的筆記本電腦，給我你的桌面和電視。問題是你可能沒有我想要的東西，所以我們不能交易。 解決方案是適配器模式。我們不能交易，因爲我們有不兼容的接口（想要）。所以錢被髮明瞭。所以現在如果你想要我的筆記本電腦，通過適配器，典當它，並獲得一些錢。是啊！我絕對想要一些錢。幾乎每個人都實現了稱爲Money的抽象類（或者其中Dollars是實例的IMoney）。你做？ 現在與命令模式相比，貨幣沒有關於接收器的信息。我希望錢是我作爲接收者的命令對象。那太酷了。但不是！而票可以被調用，撤消或重做等，錢總是被接受。如果你給我一些，我會做一件事：接受它。

Answer 4

在命令模式中，命令對象知道能夠完成給定請求的人。或者也可能知道誰是所有需要的人，以完成請求。 （例如：如果請求是「洗滌」，命令對象獲取衣服，找到洗衣機，放入洗滌劑，旋動機器並完成處理。對於這些操作，它可以調用其他人（物體）。

在適配器模式中，適配器不知道那個能夠完成工作的人，也不知道任何關於請求或如何完成工作的信息，只是調用另一個人已經實現了非兼容接口