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