《大話設計模式》將于11月底由清華大學出版社出版

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

（接上篇）
?

29.6? 行為型模式一組比賽

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

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

13號選手 觀察者（Observer）

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

?

14號選手 模板方法（TemplateMethod）

?

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

15號選手 命令（Command）

?

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

16號選手 狀態（State）

?

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

17號選手 職責鏈（Chain of Responsibility）

?

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

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

ADO.NET：“是的，最早是BASIC，它是很古老的一個品牌，經過二十多年的發展，它已經成功地從以簡單入門為標準轉到了完全面向對象，真的很不容易，即簡單易懂，又功能強大，所以它做出的運動裝非常實用。”

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

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

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

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

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

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

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

“非常好，請問模板方法小姐，請你談談，你對代碼重復的理解以及你如何實現代碼重用？”里氏代換問。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ADO.NET：“得罪誰了？短信什么內容？”

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

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

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

(未完待續)

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

轉載于:https://www.cnblogs.com/cj723/archive/2007/11/18/962789.html

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。