哈哈，大家新年快樂(lè)。本來(lái)說(shuō)要盡快把這個(gè)話題結(jié)束的，結(jié)果因?yàn)榭荚嚕业腛pen source的project而拖到了現(xiàn)在。今天和明天盡可能的結(jié)束它們吧～謝謝大家的支持，也對(duì)我的拖延表示歉意。。。
與前兩種模式不同，一些行為型模式需要在動(dòng)態(tài)過(guò)程中才能被良好的表達(dá)，這也給這些模式的理解加深了難度。特別是在對(duì)已有系統(tǒng)進(jìn)行逆向分析的時(shí)候，對(duì)于一些混合使用了多個(gè)設(shè)計(jì)模式的組件而言，想準(zhǔn)確的弄清楚用了哪些模式，更是困難。所以對(duì)設(shè)計(jì)模式使用動(dòng)機(jī)的理解，是很重要的。
這個(gè)是題外話。
首先來(lái)討論一下Chain of responsibility
。
對(duì)于職責(zé)鏈來(lái)說(shuō)，“鏈”這個(gè)詞是關(guān)鍵。
它的一個(gè)隱含的意義就是，消息的散播有序的。這種序列可以表現(xiàn)為主從關(guān)系，或先后關(guān)系。
在運(yùn)行時(shí)，消息的傳播完全有可能是樹狀或者呈現(xiàn)DAG這樣的結(jié)構(gòu)(例如在composite中)。它適合于消息傳播層次化的時(shí)候，如果不同對(duì)象之間的消息溝通是呈現(xiàn)復(fù)雜的網(wǎng)狀或者扁平狀，那么消息鏈就完全沒(méi)有作用了。
如果消息的傳遞可以是無(wú)序的，或者不同消息接受者之間沒(méi)有明顯的主從關(guān)系，那么更適合用一些更加靈活的手法，比如signal-slot idioms。不過(guò)，signal slot與COR的關(guān)注點(diǎn)并不同，前者比后者要更加關(guān)注與實(shí)現(xiàn)細(xì)節(jié)和消息通訊的局部情況。
COR和Decorator也有一些相似之處的，只不過(guò)COR的關(guān)系是在動(dòng)態(tài)過(guò)程中體現(xiàn)，而Decorator是在靜態(tài)過(guò)程中體現(xiàn)；并且COR只是強(qiáng)調(diào)信息的轉(zhuǎn)發(fā)，而Decorator則是強(qiáng)調(diào)功能的增強(qiáng)。前者強(qiáng)調(diào)模式的協(xié)作組件間提供一個(gè)機(jī)制，以及怎樣實(shí)現(xiàn)這個(gè)機(jī)制；后者則強(qiáng)調(diào)模式的協(xié)作組件之間需要什么樣的功能邏輯。
Command是個(gè)非常強(qiáng)大的工具，它的強(qiáng)大與難以理解對(duì)很多初學(xué)者來(lái)說(shuō)都是很可怕的事情。
但是對(duì)于Command的基本理解，只需要知道它是C++版的Callback，就足夠了。同時(shí)，對(duì)于Command的使用，我認(rèn)為也僅限于Callback，如果Command的職責(zé)超出了Callback之外的用途，是需要謹(jǐn)慎對(duì)待的。Command解決了消息內(nèi)容與組件之間的耦合問(wèn)題，但是，它并沒(méi)有解決交互耦合的問(wèn)題。
以UI設(shè)計(jì)為例，使用Command可以將UI元素與邏輯之間互相不知道對(duì)方的內(nèi)容。但是，在僅僅有Commmad的情況下，邏輯必須知道“UI”的基本情況才能正確運(yùn)行（比方說(shuō)與UI一起工作，Command需要綁定哪些要素）。實(shí)際上我們對(duì)它的期望是，邏輯部分不知道UI的存在，無(wú)論是Command Line下（此Command非彼Command，哈哈）還是GUI下，甚至作為一個(gè)系統(tǒng)的子系統(tǒng)出現(xiàn)，它都能正常的工作。而為與UI協(xié)同工作的Command很有可能就具備了UI下的Command實(shí)現(xiàn)所特有的特征。這些特征在移植到其它環(huán)境下會(huì)有一些困難，并需要做出設(shè)計(jì)上的再度取舍，Command模式本身也成為了一個(gè)包袱。
其次，Command模式通常用于多對(duì)多的關(guān)系中，這使得Command在時(shí)間上和邏輯上不連貫，也會(huì)給系統(tǒng)理解帶來(lái)一定的難度。因此，如果將Command與Mediator或者COR、或者Visitor這樣的模式搭配使用，將Command理解為實(shí)踐技術(shù)與慣用手法，而將Mediator等作為設(shè)計(jì)元素來(lái)考慮的話，可能更加恰當(dāng)一些。Command提供了消息的解耦合，而其它的模式則連同通信耦合也一并解除了。
Interpretor恐怕是DP里面所討論的用途最窄的模式了。
實(shí)際上，稍微有點(diǎn)經(jīng)驗(yàn)的人，對(duì)這個(gè)模式都不陌生。Composite，Interpretor和Builder之間有著千絲萬(wàn)縷的聯(lián)系。前者體現(xiàn)了結(jié)構(gòu)上的層次，Builder則適合于構(gòu)造Composite，而Interpretor，可以作為Builder用于構(gòu)造Composite的信息源。從更加寬泛的概念講，Interpretor適合于將一種層次化的信息轉(zhuǎn)換成另外一種表達(dá)方式。最典型的例子就是帶有子結(jié)構(gòu)的類的I/O實(shí)現(xiàn)，例如將對(duì)象持久化為XML或者逆持久化，在這里面就少不了它的身影。