《大話設(shè)計模式》將于11月底由清華大學(xué)出版社出版

《大話設(shè)計模式》第29章-OOTV杯超級模式大賽—模式總結(jié)（一）
《大話設(shè)計模式》第29章-OOTV杯超級模式大賽—模式總結(jié)（二）
《大話設(shè)計模式》第29章-OOTV杯超級模式大賽—模式總結(jié)（三）

（接上篇）
?

29.6? 行為型模式一組比賽

“歡迎回到第一屆OOTV杯超級設(shè)計模式大賽現(xiàn)場，下面是第三組，也就是行為型模式一組的比賽，她們將穿VB.NET運動裝出場。”

“首先出場的是13號選手，觀察者小姐入場，它的口號是定義對象間的一種一對多的依賴關(guān)系，當(dāng)一個對象的狀態(tài)發(fā)生改變時，所有依賴于它的對象都得到通知并被自動更新。[DP]”

13號選手 觀察者（Observer）

“14號選手，模板方法小姐，她提倡定義一個操作的算法骨架，而將一些步驟延遲到子類中，模板方法使得子類可以不改變一個算法的結(jié)構(gòu)即可重定義該算法的某些特定步驟。[DP]”

?

14號選手 模板方法（TemplateMethod）

?

“15號選手是命令小姐，它覺得應(yīng)該將一個請求封裝為一個對象，從而使你可用不同的請求對客戶進(jìn)行參數(shù)化；可以對請求排隊或記錄請求日志，以及支持可撤銷的操作。[DP]”

15號選手 命令（Command）

?

“16號是狀態(tài)小姐，她說允許一個對象在其內(nèi)部狀態(tài)改變時改變它的行為，讓對象看起來似乎修改了它的類。[DP]”

16號選手 狀態(tài)（State）

?

“本組最后一位，17號選手，職責(zé)鏈小姐，她一直認(rèn)為使多個對象都有機(jī)會處理請求，從而避免請求的發(fā)送者和接收者之間的耦合關(guān)系。將這些對象連成一條鏈，并沿著這條鏈傳遞該請求，直到有一個對象處理它為止。[DP]”

17號選手 職責(zé)鏈（Chain of Responsibility）

?

觀眾席中的ADO.NET和Hibernate又開始了討論。

Hibernate ：“VB.NET是你們.NET家族的品牌吧？”

ADO.NET：“是的，最早是BASIC，它是很古老的一個品牌，經(jīng)過二十多年的發(fā)展，它已經(jīng)成功地從以簡單入門為標(biāo)準(zhǔn)轉(zhuǎn)到了完全面向?qū)ο?#xff0c;真的很不容易，即簡單易懂，又功能強(qiáng)大，所以它做出的運動裝非常實用。”

Hibernate：“行為型模式的小姐們長得怎么都不太一樣，風(fēng)格差異也太大了。我不喜歡。”

ADO.NET：“我卻覺得還不錯，它們大多各有各的特長，比如這一組，應(yīng)該還是有點看頭，觀察者、模板方法、命令都算是比較強(qiáng)的選手。”

Hibernate ：“多半是觀察者勝出了，因為她實在是到處接拍廣告，做宣傳，什么地方都能見到她的蹤影，恨不得通知所有人，她是一設(shè)計模式。”

ADO.NET：“我猜也是她，人家本來就是以通知為主要魅力點的模式呀。咱們拭目以待吧。”《大話設(shè)計模式》

“下面有請評委提問。”主持人GOF說。

“請問觀察者小姐，說說你對解除對象間的緊耦合關(guān)系的理解？”依賴倒轉(zhuǎn)問道。

“我覺得對象間，尤其是具體對象間，相互知道的越少越好，這樣發(fā)生改變時才不至于互相影響。對于我來說，目標(biāo)和觀察者不是緊密耦合的，它們可以屬于一個系統(tǒng)中的不同抽象層次，目標(biāo)所知道的僅僅是它有一系列的觀察者，每個觀察者實現(xiàn)Observer的簡單接口，觀察者屬于哪一個具體類，目標(biāo)是不知道的。”

“非常好，請問模板方法小姐，請你談?wù)?#xff0c;你對代碼重復(fù)的理解以及你如何實現(xiàn)代碼重用？”里氏代換問。

模板方法說，“代碼重復(fù)是編程中最常見、最糟糕的‘壞味道’，如果我們在一個以上的地方看到相同的程序結(jié)構(gòu)，那么可以肯定，設(shè)法將它們合而為一，程序會變得更好[RIDEC]。但是完全相同的代碼當(dāng)然存在明顯的重復(fù)，而微妙的重復(fù)會出現(xiàn)在表面不同但是本質(zhì)相同的結(jié)構(gòu)或處理步驟中[R2P]，這使得我們一定要小心處理。繼承的一個非常大的好處就是你能免費地從基類獲取一些東西，當(dāng)你繼承一個類時，派生類馬上就可以獲得基類中所有的功能，你還可以在它的基礎(chǔ)上任意增加新的功能。模板方法模式由一個抽象類組成，這個抽象類定義了需要覆蓋的可能有不同實現(xiàn)的模板方法，每個從這個抽象類派生的具體類將為此模板實現(xiàn)新方法[DPE]。這樣就使得，所有可重復(fù)的代碼都提煉到抽象類中了，這就實現(xiàn)了代碼的重用。”

“下面請問命令小姐，為什么要將請求發(fā)送者與具體實現(xiàn)者分離？這有什么好處？”單一職責(zé)問道。

“您的意思其實就是將調(diào)用操作的對象與知道如何實現(xiàn)該操作的對象解耦，而這就意味著我可以在這兩者之間處理很多事，比如完全可以發(fā)送者發(fā)送完請求就完事了，具體怎么做是我的事，我可以在不同的時刻指定、排列和執(zhí)行請求。再比如我可以在實施操作前將狀態(tài)存儲起來，以便支持取消/重做的操作。我還可以記錄整個操作的日志，以便以后可以在系統(tǒng)出問題時查找原因或恢復(fù)重做。當(dāng)然，這也就意味著我可以支持事務(wù)，要么所有的命令全部執(zhí)行成功，要么恢復(fù)到什么也沒執(zhí)行的狀態(tài)。總之，如果有類似的需求時，利用命令模式分離請求者與實現(xiàn)者，是最明智的選擇。”

“OK，職責(zé)鏈小姐，提問命令小姐的問題同樣提問給你，為什么要將請求發(fā)送者與具體實現(xiàn)者分離？這有什么好處？你如何回答。”

“我們時常會碰到這種情況，就是有多個對象可以處理一個請求，哪個對象處理該請求事先并不知道，要在運行時刻自動確定，此時，最好的辦法就是讓請求發(fā)送者與具體處理者分離，讓客戶在不明確指定接收者的情況下，提交一個請求，然后由所有能處理這請求的對象連成一條鏈，并沿著這條鏈傳遞該請求，直到有一個對象處理它為止。”職責(zé)鏈答道，“比如我住在縣城，生了怪病，我不知道什么級別的醫(yī)院可以診治，顯然最簡單的辦法就是馬上找附近的醫(yī)院，讓此醫(yī)院來決定是否可以治療，如果不能則醫(yī)院會提供轉(zhuǎn)院的建議，由縣級轉(zhuǎn)市級、由市級轉(zhuǎn)省級、由省級轉(zhuǎn)國家級，反正直到可以治療為至。這就不需要請求發(fā)送者了解所有處理者才能處理問題了。”

“非常好，例子很形象，不過得怪病不是好事，健康才最重要。”開放封閉微笑道，“下面請問最后一位，狀態(tài)小姐，條件分支的大量應(yīng)用有何問題？如何正確看待它？”

狀態(tài)答道：“如果條件分支語句沒有涉及重要的商務(wù)邏輯或者不會隨著時間的變化而變化，也不會有任何的可擴(kuò)展性，換句話說，它幾乎不會變化，此時條件分支是應(yīng)該使用的。但是注意我這里用到了很多前提，這些前提往往都是不成立的，事實上不會變化的需求很少，不需要擴(kuò)展的軟件也很少，那么如果把這樣的分支語句進(jìn)行分解并封裝成多個子類，利用多態(tài)來提高其可維護(hù)、可擴(kuò)展的需要，是非常重要的。狀態(tài)模式提供了一個更好的辦法來組織與特定狀態(tài)相關(guān)的代碼，決定狀態(tài)轉(zhuǎn)移的邏輯不在單塊的if或switch中，而是分布在各個狀態(tài)子類之間，由于所有與狀態(tài)相關(guān)的代碼都存在于某個狀態(tài)子類中，所以通過定義新的子類可以很容易地增加新的狀態(tài)和轉(zhuǎn)換。[DP]”《大話設(shè)計模式》

“下面有請六位評委寫上你們認(rèn)為表現(xiàn)最好的模式小姐。”GOF說道。

“喔，觀察者3票、模板方法2票、命令1票，最終觀察者小姐晉級。”GOF在等評委翻牌后宣布道。“恭喜你，觀察者小姐，有什么要說的嗎？”

觀察者小姐平靜地說：“感謝所有關(guān)心我、喜歡我和憎恨我的人。比賽中的環(huán)境不太干凈，但我是干凈地站起來的。”

“啊，你，你說憎恨？不干凈？什么意思？”GOF非常意外。

“無可奉告。”觀察者顯然知道剛才那些話的影響，所以選擇回避。

“哦，”GOF有些尷尬，“下面先進(jìn)段廣告，廣告后我們進(jìn)行第四組的比賽。”慌忙之中，GOF連讓短信投票的宣傳都忘記說了。

此時場下觀眾都議論紛紛。當(dāng)然ADO.NET和Hibernate兩位也不例外。

ADO.NET：“你說她被誰憎恨了？”

Hibernate ：“那誰知道。不過一定是來參賽前，受到了一些阻撓，甚至于產(chǎn)生了很大的矛盾，因此才有了憎恨一說。其實憎恨也就罷了，‘不干凈’一詞力道可就重了。”

ADO.NET：“這有什么，只不過觀察者她膽子大，說了出來。在娛樂圈、體育圈有潛規(guī)則，難道我們程序世界里就沒有潛規(guī)則？”

Hibernate ：“是呀，只要涉及到利益，就不可能沒有交易。我再給你爆個料，MVC你聽說過嗎？”

ADO.NET：“知道呀，大名鼎鼎的MVC模式，就是Model/View/Controller，非常漂亮的姑娘。在電視上經(jīng)常能看到它，好像談模式、談架構(gòu)沒有不談到她的。”

Hibernate ：“你可知道為何她沒來參加這次超級模式大賽？”

ADO.NET：“咦，對哦，為什么她沒來參加呢，要是她來，和這23個比，至少前三是一定可以進(jìn)的。你不要告訴我，因為她被潛規(guī)則了？”

Hibernate ：“我偷偷告訴你，你可別出去亂傳。MVC是包括三類對象，Model是應(yīng)用對象，View是它在屏幕上的表示，Controller定義用戶界面對用戶輸入的響應(yīng)方式。如果不使用MVC，則用戶界面設(shè)計往往將這些對象混在一起，而MVC則將它們分離以提高靈活性和復(fù)用性[DP]。因此，有人甚至說，她是集觀察者、組合、策略三個美女優(yōu)點于一身的靚女。海洗和選拔賽時她都表現(xiàn)非常好的，但因為一次短信的事情，而她又在自己博客里寫了《非得這樣嗎？》的文章，大大地得罪了主辦方的一個大鱷。于是由于這件事，她就徹底把自己的前途給葬送了。后來博客的文章也被勒令刪除。”

ADO.NET：“得罪誰了？短信什么內(nèi)容？”

Hibernate：“我哪知道呀，反正她后來就退出比賽了。”

ADO.NET：“你這也叫爆料呀，什么都沒說出來，根本就一個聽風(fēng)是雨沒任何根據(jù)的小道消息。據(jù)我猜測，主要原因是這次是設(shè)計模式比賽，而MVC是多種模式的綜合應(yīng)用，應(yīng)該算是一種架構(gòu)模式，所以被排除在外。”

Hibernate：“不信就算了，不過你說的也有道理。”《大話設(shè)計模式》

(未完待續(xù))

再次聲明一下，本29章，可以代表本書的幽默風(fēng)格，卻不能代表本書的講解技術(shù)的方式。正因為這一章的最與眾不同，我本想讓朋友們可以從全新的視角去看待23個設(shè)計模式，回顧一下它們的相同與不同。可惜是劍就有雙刃，我忽略了有很多朋友是不了解《小菜編程成長記》的，以為本書全是這種娛樂化的書寫，因此得出這樣的文字不能得到收獲結(jié)論。事實并非如此，否則出版社也不會出版本書，而只會讓它上IT娛樂雜志了。在將此章結(jié)束后，我會帖出講解設(shè)計模式的樣章，希望您繼續(xù)關(guān)注。

轉(zhuǎn)載于:https://www.cnblogs.com/cj723/archive/2007/11/18/962789.html

《新程序員》：云原生和全面數(shù)字化實踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的《大话设计模式》第29章-OOTV杯超级模式大赛—模式总结（四）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。