重新整理Command Pattern

August 06 21:00~22:30；13 08:47~12:00

 

休息了幾天的「重新整理設計模式」這一系列文章又回來了，今天介紹Command模式。這個Command 模式，跟Observer一樣，雖然經常使用而且實作上也不難，卻反而不容易描述清楚。真的是應驗了「越簡單越難」這句話。接下來直接看整理後的結果。

***

Name：Command

Context：有時候客戶端針對同一類型的事件或是請求動作，需要呼叫不同物件來處理，而這些物件的介面通常都不相同。你可以將呼叫不同介面物件的方式直接寫在客戶端身上，但是這麼做每次只要有新的物件加入都需要直接修改客戶端的程式碼，或是要繼承原有的客戶端然後在子類別內完成新增加的實作。如果系統中有多個客戶端都會執行相同的動作，例如使用者可以透過應用程式的「菜單」與「工具列」來執行相同的列印功能，則一不小心很容易產生重複程式碼。

如果可以去除客戶端與被呼叫物件的耦合關係便可增加系統的彈性。更進一步連選擇執行哪一個物件的某個方法，以及在什麼執行點來啟動這個執行的動作這兩件事也可以彼此獨立，那就更好了。

Problem：如何發出請求給一個物件？

Force：

• 為了避免在客戶端產生與型別有關的條件判斷式，你希望以相同的呼叫方式來呼叫不同介面的物件。
• 不合適讓不同介面的物件都實作相同的介面，因為這麼做不但需要拿到物件的原始碼，而且會讓原本物件擁有看起來不屬於自己責任的介面。
• 你希望可以動態配置實作請求的方式。

Solution：將請求封裝成物件。定義一個Command介面，包含一個execute方法。讓ConcreteCommand實作Command介面，在execute方法中撰寫呼叫物件（Receiver）的程式碼。客戶端程式透過呼叫Command介面的execute方法來發出請求給不同的物件。

***

這個Command模式整理了好久，總算生出一個版本出來。歡迎四方大德批評指教。

***

友藏內心獨白：6/23，完成率26.09%。