命令模式似乎不必要的複雜（我不明白什麼？）

Question

我已經閱讀了命令模式，我想我錯過了一些東西。 Command對象用於抽象出Receiver對象的詳細信息。在我看來，我們可以簡單地在這裏停下來，並持有對Command對象的引用以在適當的時候執行適當的方法。

那麼爲什麼需要調用者？這種額外的間接提供了什麼好處？我們已經隱藏了接收者在命令後面的細節，那麼命令對客戶隱藏的動機是什麼？

Answer 1

好吧，如果你這樣說，看起來相當複雜，但通常Receiver並不需要成爲一個對象。它可能不僅僅是一個被執行的函數（作爲一個事件）。另外，調用者不需要成爲一個類。這只是觸發命令的事情。這也可以是按鈕中的事件處理程序。

即使Wikipedia總結了幾個例子，其中使用這種模式，而實際上並不需要爲調用者和接收者實現完整的單獨的類。一個例子是嚮導對話框，其中GUI填充命令對象，並且完成按鈕觸發它。所以GUI類（無論如何）都是客戶端和調用者。

Answer 2

從我所知道的情況來看，模式的要點是有某種命令生產者和某種命令使用者，但允許生產者創建或修改命令而不需要消費者改變。

該模式調用生產者「客戶」和消費者「調用者」。

這是一個OO回調。

那麼，爲什麼是祈求需要

至於我可以告訴all the examples on Wikipedia，調用者並沒有一個明確的形式。它只是一些接受抽象命令的代碼。

在我看來，我們可以簡單地停在這裏，並保持引用Command對象

如果它在你的調用命令，接受或容納抽象指令引用的東西代碼有道理，那麼你已經實現了調用者。

如果一位代碼既是生產者又是消費者，命令模式是毫無價值的。當你將抽象命令傳遞給某些想要調用它們的東西時，這纔是值得的。

Answer 3

如果您通過不同類型的命令，Invoker是有用的。你可以使用相同的Invoker來執行不同的具體命令。在不同的節點上，標記Receiver與ConcreteCommand而不是Invoker允許鬆耦合。該Receiver可以改變方法（如合閘合閘到swithcOnTV）的名稱，如本例：

相關崗位：Using Command Design pattern

要了解的Invoker的目的，我想你在餐廳&請參閱本article汽車服務中心使用案例。

服務員（Invoker）從他的墊上從Customer採取訂單。然後將Order排隊等待的順序廚師，並得到在那裏處理的廚師（Receiver）。

客戶是Customer。他通過服務員，誰是Invoker送他的請求Receiver。服務員封裝通過寫它的檢查命令（在這種情況下，指令），然後放置它，創造ConcreteCommand對象，它是命令本身。

的Receiver將是，對所有正在討論的命令之前發送給他的命令完成下班後，就可以開始工作的廚師。

的例子中另一個值得注意的方面是，對於訂單的墊不會從菜單中只支持訂單，因此它可以支持的命令做飯許多不同的項目的事實。