讀處

Command Pattern

Encapsulate a request as an object, thereby letting you parameterize clients with
different requests, queue or log requests, and support undoable operations.  ─《GOF》

將請求封裝為物件，使你藉由不同的請求 (如: 佇列或日誌請求)，
對客戶端請求參數化，並支援可取消的操作。

我們先來看一下範例好了:

如果今天客戶端給你了一個Light的介面

希望你能夠寫一個遙控器的程式可以操控電燈

這個電燈的介面非常簡單，就只有開燈與關燈的功能

在Command Pattern我們有個專有名詞稱呼Light這個Class 

一般我們稱作Receiver 是負責執行命令的內容

那接下來我們可以來定義一個Command介面

在這個介面中我們只定義一個execute的方法，協助我們執行命令

接下來我們就可以來實作兩個Concrete Command : LightOnCommand , LightOffCommand

透過這兩個Concrete Command 去操作Light的開關功能

接下來我們可以來實作遙控器的程式

而這個遙控器的程式在Command Pattern一般稱作 Invoker 負責儲存與呼叫命令

最後，我們就可以看看Client如何利用遙控器操作電燈的開關功能

▲那這就是目前我們實作後的class diagram

看完這個例子後，你可能會覺得，就這麼簡單啊!

對阿...因為我特意挑了一個很簡單的例子

那Command Pattern到底對我們有什麼好處

OK,假設今天你的客戶又跑來跟你說

我的這個遙控器阿，希望能夠開關冷氣，我把開關冷氣的介面給你

這應該很簡單可以做到吧?

你可以非常理直氣壯地跟你的客戶說，那當然，我可是套用了Command Pattern

那我們的設計就會變成下面這樣

也就是說，我的程式非常容易擴充，很有彈性

可以達到敏捷開發強調的擁抱改變~~

我大概就寫到這邊了...

總是有很多地方寫的不夠詳盡，不夠清楚

尤其是我覺得我沒有很強烈讓大家感受到套用Command Pattern的force

所以歡迎大家參考Teddy的這篇文章 重新整理Command Pattern

Teddy將Context, Problem, Force , Solution寫得非常詳盡

參考:

[1] https://dzone.com/articles/design-patterns-command

[2] https://notfalse.net/4/command-pattern

[3] http://teddy-chen-tw.blogspot.com/2013/08/command-pattern.html