作為C++的堅實粉絲，我一直很排斥JAVA，并不是JAVA這種語言不好，而是Java迷的那副嘴臉，事事都要與C++爭，并且還堅稱JAVA比C++，甚至連執(zhí)行效率都要勝過C++，什么JIT運行時能監(jiān)視代碼，選取執(zhí)行頻率最高的代碼，根據(jù)特定的平臺，進行特別處理，生產(chǎn)出最優(yōu)化的機器代碼；又說什么垃圾回收能夠解決C++中的內(nèi)存管理問題，并且內(nèi)存分配遠遠勝過C++中的手工人肉管理內(nèi)存的毛病，其實，內(nèi)存管理從來就不是C++中的嚴重問題，只要設(shè)計得好，應用層中的代碼甚少可以不出現(xiàn)new， delete。至少delete可以不出現(xiàn)，大家知道WHY的；種種論調(diào)，無理取鬧之極。而最令我受不了的，就是他們閉口開口，都離不開設(shè)計模式，搞得設(shè)計模式好像成為了JAVA的專有產(chǎn)品。須知，第一本設(shè)計模式的書，也是最最經(jīng)典的那本四人書，其對設(shè)計模式的實現(xiàn)語言，采用的就是SmallTalk 和C++，一開始就不關(guān)JAVA的一點事情，并且書中C++還占了較大的比重。關(guān)于四人書，最讓我欣慰的一件事情就是，四位巨頭并沒有響應JAVA迷的強烈呼聲，采用JAVA來實現(xiàn)設(shè)計模式的第二版。當然，我也承認，用JAVA來實現(xiàn)設(shè)計模式，確實來得要比C++清爽，JAVA的這種語言，好像就是專為設(shè)計模式量身訂做。只可惜，市面上任何一本JAVA的設(shè)計模式書，沒有一本及得上我們C++的那一本設(shè)計模式圣經(jīng)，C++中不必再需要設(shè)計模式的書了，因為最好的書就已經(jīng)擺在那里了，涵蓋了設(shè)計模式中的方方面面，濃縮精華得很。突然想起，C++的教材也不需要那么多，因為老爺子已經(jīng)寫了一本最好的書了，其他書的內(nèi)容，都已經(jīng)涵蓋在那本C++語言圣經(jīng)中了。至于那些不被C++圣經(jīng)所提及的，那都是一些走火入魔的玩意，玩玩還可以，開闊開闊視野也不錯，但真要用在實際項目中，還是少用為妙。罪過罪過，C++中的好書確實有好幾本，不宜一棍子打死。
有趣的是，設(shè)計模式在JAVA中被捧上了天，沒有設(shè)計模式，JAVA就沒法活下去。反而C++作為設(shè)計模式的第一實現(xiàn)語言，卻不怎么感冒。不能說被輕視，但起碼沒有普遍被重視。即使C++中的高手，也沒有對設(shè)計模式如何如何的推崇備至，他們貌似更加喜歡玩語法糖，熱衷于在C++中模擬出其他語言的特性。這也難怪，C++有四種編程典范，設(shè)計模式的主要應用就在于面向?qū)ο螅嫦驅(qū)ο蟛贿^是其中最不成熟的一種，在C++中，最成熟的要數(shù)基于對象的編程，當然，拜C語言成熟，面向過程也熟得要爛了，泛型這東西也挺前衛(wèi)的，而C++中的面向?qū)ο螅恢背裘阎瑹o論怎么努力，都難以搬上臺面。注意，C++中的面向?qū)ο笈c虛函數(shù)是兩碼事，至少在我看來是這樣的。
好了，該談談我對設(shè)計模式的看法了，一句話，我對設(shè)計模式殊無好感，源于我內(nèi)心對當前的面向?qū)ο缶幊田L格的排斥，因為那是偽面向?qū)ο缶幊蹋^的偽面向?qū)ο螅褪侵竿ㄟ^單根繼承和針對接口或抽象類來寫代碼，就以為是在進行面向?qū)ο蟮木幊蹋菍嵲谑翘煺媪恕ＴO(shè)計模式中的那些點子，用得好，確實能解決偽面向?qū)ο蟮囊恍﹩栴}，無可厚非；用得不好，無緣無故地引入一些不必要的東西，模式的應用意味著間接性的增厚。現(xiàn)實中，能恰當?shù)赜煤媚Ｊ降娜耍僦稚伲Ｊ娇偸浅霈F(xiàn)在一些不必要出現(xiàn)的場合下。很多人都是生吞活剝了23種模式之下，內(nèi)心就沾沾自喜，到處躍躍欲試，鮮有人嘗試理解模式背后的統(tǒng)一思想是什么，或者說，如果代碼本身就已經(jīng)能夠很好類與類之間的耦合問題，可勝過千萬種設(shè)計模式。
以下文字，與孟巖大俠的觀點，存在部分重復之處，讀者認為在下是在拾他的牙慧，我也不反對，畢竟人家的文章反表在前，我無話可說，本文的重點，旨在表達在下對設(shè)計模式的鄙視。
既然有偽面向?qū)ο螅陀姓婷嫦驅(qū)ο蟆Ｕ婷嫦驅(qū)ο蟮木幊蹋褪悄阒恢酪粋€對象的ID，其他的一切事情，它繼承自那些父類，實現(xiàn)了那些接口，統(tǒng)統(tǒng)一概都不得而知，然后你只能通過這個ID給對象發(fā)送消息，以此來驅(qū)使對象做一些事情，注意，確確實實是只是發(fā)送消息，而不是調(diào)用該對象的函數(shù)，那怕是調(diào)用了該對象實現(xiàn)的接口函數(shù)，也意味著該對象的依賴，好吧，說錯了，是對該接口的依賴，不管怎么樣，都是依賴，而且依賴接口，還搞得客戶代碼和對象都要依賴于同一個接口了。
給對象發(fā)送消息，聽起來似乎有點抽象，但是，只要聯(lián)想到WINDOWS的窗口句柄和消息處理函數(shù)，就自然明白是怎么回事了。在WINDOWS下，每一個窗口都是一個對象，窗口句柄代表了對象ID。操作窗口時，只能通過SendMessage或PostMessage來讓窗口作一些事情。SendMessage或PostMessage的四個參數(shù)，分別是對象ID、消息編號、消息參數(shù)1和消息參數(shù)2。客戶代碼在使用窗口時，不需要假設(shè)什么接口，能做的，僅須做的，僅僅就是給它發(fā)送消息，客戶代碼完全無須依賴于什么鬼接口，非常簡單明了。但是，這里存在一個問題，消息參數(shù)1和消息參數(shù)2都是void*類型，不安全耶，要是誤發(fā)送錯了消息，那該怎么辦。在偽面向?qū)ο笾校蛻粢部赡茉谡{(diào)用接口參數(shù)時，也可能會傳錯了參數(shù)，只不過是編譯器可以幫你找出來。其實類型不安全，也沒什么，客戶既然要發(fā)送消息給對象，自然要遵守使用的協(xié)議，自然要清楚自己在做什么事情，這本來就是C語言的精神，一切相信程序員。
好了，該是給WINDOWS大唱贊歌了。WINDOWS系統(tǒng)的窗口是我見過中算是比較象樣的面向?qū)ο蟮牡浞读恕⒚嫦驅(qū)ο蟮木褙瀼氐降祝翱趯ο蠛芎玫刈龅搅藘H僅是純粹解析消息，執(zhí)行消息，與外界的其他對象，不存在任何一點耦合。一個窗口對象中的lpfnWndProc其實可以理解成指向虛函數(shù)表的指針，但是它卻要比虛函數(shù)表的指針功能更加強大靈活，并且還不存在虛擬函數(shù)表的種種問題。強大之處，就之于lpfnWndProc相當于指向一個龐大的虛函數(shù)表，這個表有2的32次方多個虛函數(shù)，靈活之處可以突破虛函數(shù)的種種限制。當你要給一個窗口對象添加新的功能，或者不滿意它的某些原有操作的時候，你完全可以子類化該窗口，在子類化操作中，截取關(guān)心的消息，解析消息，執(zhí)行消息，至于其他的消息，直接交給lpfnOldWndProc或DefWindowProc就是了。從這個意義上講，所有的窗口對象繼承于DefWindowProc，而子類化窗口即是繼承于lpfnOldWndProc，但是，這里的繼承，卻沒有偽面向?qū)ο笾械睦^承或?qū)崿F(xiàn)接口的種種弊端。而且，在你子類化窗口的時候，不用影響到客戶的任何一點點代碼，客戶代碼依舊是發(fā)送消息，卻不知道窗口對象已經(jīng)舊貌換新顏了，OH，這實在太美妙了。所有的耦合，奇跡般的消失得干干凈凈了。消息比之于接口，那完完全全是純粹的正交關(guān)系，并且沒有接口的種種累贅，種種缺陷。并且更爽的是，即使對象沒有處理消息，也沒有關(guān)系，客戶代碼依然可以給對象發(fā)送消息。
從某種意義上講，設(shè)計模式不過是為了解耦對象與對象之間的耦合關(guān)系，當對象之間不存在耦合的時候，設(shè)計模式還有什么存在的意義嗎？以下結(jié)合WINDOWS系統(tǒng)來理解，所謂的設(shè)計模式，不過是消息發(fā)送的一些應用罷了。下面的舉例，例子之間沒有什么必然關(guān)系，我想到那里就寫到什么，模式后面似乎應該帶上英文，但我也懶得寫了。
觀察者模式：一個廣播消息就搞定了；
模板方法：不過是按順序給一個對象發(fā)送某些指定的消息而已；
工廠方法、抽象工廠：用一個或幾個lpClassName就搞定了；
原型：不過是發(fā)送一條WM_COPYOBJECT的消息而已；
裝飾者或者狀態(tài)：嘿，子類化就完成了，并且非常徹底，一點都不覺得別扭；
命令：對象將SendMessage中的消息編號、消息參數(shù)1和消息參數(shù)2保存起來就是了，這沒什么大不了的；
策略：不過一個回調(diào)函數(shù)，外加必要的參數(shù)；
橋接：貌似沒什么必要；
……
沒有了！落得個一片白茫茫大地真干凈！