Command模式：
Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. － 《Design Patterns》 
Command模式的關(guān)鍵在于只包含一個 Execute方法，子類在實現(xiàn)這個接口時，在Execute方法中，完成特定的任務(wù)。可以說，這是一個非常簡單的模式。
《ASD》中提到了該模式的三種用法：
1. Invoker可以和任意一個Command掛鉤，而且不需要了解這到底是個什么ConcreteCommand，然后在需要的時候調(diào)用這個 Command對象的Execute方法就行了。這在消息驅(qū)動的的系統(tǒng)中非常常見，每個trigger就是一個invoker。那么如何把Command 和invoker掛鉤呢？方法很多，最cool的方法是在系統(tǒng)外用一個配置文件來指定。這樣不需要重新編譯就可以改變軟件運行的方式。可以參考 Source Insight的界面。Source Insight中可以任意配置菜單項和工具欄按鈕。其實現(xiàn)應(yīng)該就是應(yīng)用了這種Command模式。
2. 上面的方法是否讓人想起了Template模式？有點相像吧。順著這個思路去想，就可以把Command模式應(yīng)用于Transaction。讓一個類來解決Transaction的init和uninit問題，中間包含一個Command的隊列。這樣就可以把這個隊列中的全部command當(dāng)作一個 transaction了。這樣的作法可以把Transaction的實現(xiàn)和邏輯分離開來，是很漂亮的實現(xiàn)。同樣的思路，也可以用在類似的問題上，需要 init和uninit，中間有不定量的操作。
3.如果真的用來解決transaction問題，那么就必須具備roll back的能力。然而這個很容易實現(xiàn)，只要在command類中，添加undo方法就可以了。剩下的活交給invoker來處理。
4.此外還有一個附帶的好處。command類和一個單獨的execute方法其實很相似，但是command類的對象有生命周期，可以由程序來控制。因此，一個command對象，可以在提交了很長時間以后再批量執(zhí)行。
除了這些以外，《Design Pattern》還提到了Command模式的其他使用方法。雖然這些方法未必實用，但我還是把它們列在這里：
1.command對象和command對象的序列都可以serialization。這樣如果軟件被有意或無意的中止（例如crash），在重新啟動后，還可以接續(xù)之前沒有完成的任務(wù)。
2.Command模式如果和Composite模式接合，就可以作出MacroCommand。^_^，這個idea雖然很cool，但是可以用到的地方大概不多吧。
Active Object模式不屬于《Design Pattern》23模式。實際上，她是一種特殊的Command Queue。其特殊之處在于：
1. 隊列的擁有者會順序地執(zhí)行隊列中所有Command對象的Execute方法。（這個其實不算特殊）
2.Command對象在自己的Execute方法結(jié)束前，可以把一個新的command對象（實際上常常是這個command對象自己）再加到隊列的尾部。
看出來了嗎，這個隊列有可能不會終止的，他可以一直執(zhí)行下去。這個可以作為一個應(yīng)用或者服務(wù)的主模塊了，想像一下她可以作多少事情吧。
《ASP》指出這個模式可以用來在一個線程中處理多任務(wù)的問題！！！ ^_^ 太cool了。
如何處理呢？你可以把每個command對象看作是一個任務(wù)。他在Execute函數(shù)中，處理自己的任務(wù)，在任務(wù)告一段落時，記錄自己的狀態(tài)，然后把自己插入到隊列的尾部，結(jié)束Execute方法。當(dāng)隊列輪完一周后，又會再次執(zhí)行這個command對象的Execute方法。 ^_^ 很cool吧。
那么這種方法和多線程的方法相比有什么有缺點呢？
最大的優(yōu)點是，所有的command都在同一個線程中，因此切換時，不需要進入內(nèi)核模式！！超高效啊！！而且，可以有很多很多的command，數(shù)量上遠(yuǎn)遠(yuǎn)超過多線程的數(shù)量。
缺點嘛，是這種方法需要用戶自己來實現(xiàn)調(diào)度，另外這其實是一種非剝奪模式的多任務(wù)，如果command處理不好，就會連累其它所有的command，因此實際上比多線程要更復(fù)雜。（嘿嘿，程序員能夠怕麻煩嗎？）
還有一點，Active Object運行于單線程，也就是說，她不能享受多處理器或多處理器核心帶來的性能上的改善。
其實，這最后一點是非常致命的一點。也就是說，在當(dāng)前intel的超線程CPU機器上，如果系統(tǒng)的負(fù)擔(dān)并不重的時候。Active Object的效率有可能比多線程更低。
Anyway，這是一個非常有趣的模式。只是一般的程序員可能沒有機會用到。但是請記住她，也許能有那么一次機會，可一用她來爽上一把。