王垠：解密“設計模式”
有些人問我，你說學習操作系統的***辦法是學習程序設計。那我們是不是應該學習一些“設計模式”（design patterns）。這是一個我很早就有定論，而且經過實踐檢驗的問題，所以想在這里做一個總結。
總的來說，如果光從字面上講，程序里總是有一些“模式”可以發掘的。因為你總是可以借鑒以前的經驗，來構造新的程序。你可以把這種“經驗”叫做“模式”?？墒亲詮摹?a target="_blank">設計模式》（通常叫做 GoF，“Gang of Four”）這本書在 1994 年發表以來，“設計模式”這個詞有了新的，扭曲的含義。它變成了一種教條，帶來了公司里程序的嚴重復雜化。
GoF 借鑒的是一個叫 Christopher Alexander 的建筑師的做法。Alexander 給一些建筑學里的“設計模式”起了名字，試圖讓建筑師們有一些“共同語言”?？上У氖牵珹lexander 后來自己都承認，他的實驗失敗了。因為這些固定的模式，并沒有有效地傳遞精髓的知識，沒有能讓新手設計出好的建筑。照搬模式東拼西湊，而不能看透事物的本質，其實是設計不出好東西的。
當我聽說這本書的時候，我已經學會了函數式編程，正在 Cornell 讀 PhD，專攻程序語言設計。有一天由于好奇這書為什么名氣這么大，我從圖書館借了一本回來看。我很快的發現，其實這本書的作者只是給早已經存在的編程方法起了一些新的名字而已。當時我就拿起一張紙，把所有的 20 來個設計模式跟我常用的編程概念做了一個映射。這個映射居然是“多對一”（many-to-one）的。也就是說，多個 GoF 設計模式，居然只對應同一個我每天都用的概念。有些概念是如此的不值一提，以至于我根本不需要一個名字來描述它，更不要說多個名字！
其中極少數值得一提的“模式”，也許是 visitor 和 interpreter。很可惜的是，只有很少的人明白如何使用它們。所謂的 visitor，其實本質上就是函數式語言里的含有“模式匹配”（pattern matching）的遞歸函數。在函數式語言里，這是多么輕松的事情。可是因為 Java 沒有模式匹配，所以很多人使用 visitor pattern。為了所謂的“通用性”，他們往往把 visitor pattern 搞出多層繼承關系，讓你轉幾道彎也搞不清楚到底哪個 visitor 才是干實事的。
其實，函數式語言的研究者們早就知道 visitor pattern 是怎么得來的。如果你想知道如何從無到有，“發明”出 Java 的 visitor pattern，可以參考 Dan Friedman 跟他的學生 Matthias Felleisen 合寫的的另一本“小人書”《A Little Java, A Few Patterns》（發表于 1997 年）。
而 interpreter （解釋器）模式呢？看了作者們寫的例子程序之后，我發現他們其實并不會寫解釋器，或者說他們不知道如何寫出優雅的，正確的解釋器。如果你想知道如何寫出好的解釋器，可以參考我的博文《怎樣寫一個解釋器》。
你說我在貶低這本書的真正價值，因為 GoF 說了：“我們的貢獻，就是給這些編程方式起名字。這樣讓廣大程序員有共同的語言。” 如果這也叫貢獻的話，我就可以寫本書，給“空氣”，“水”，“豬肉”這些東西全都起個新名字，讓大家有“共同的語言”。這不是搞笑嗎。
這不是我的一家之言，Peter Norvig 在 1998 年就做了一個演講，指出在“動態語言”里面，GoF 的 20 幾個模式，其中絕大部分都“透明”了。也就是說，你根本感覺不到它們的存在。這就像我剛才告訴你的。
在這里 Norvig 的觀點是正確的，不過需要小心一個概念錯誤。高級的“靜態語言”（能傳遞函數作為參數的），其實也可以避免大部分 GoF 設計模式。而“動態語言”這個概念，在程序語言的理論里面，其實是沒有明確的定義的。“動態語言”其實也能進行某些“靜態類型檢查”。不過在 1998 年，我還是個啥都不懂屁孩，所以這里就不跟 Norvig 大叔計較了。
既然老人們都有歷史局限性，那么為啥我還跟 GoF 找茬？本來這本書很老了，如果沒有人再被它誤導的話，這篇博文也就不必存在了?？墒钱斘以?Google 實習的時候，我發現幾乎每個程序員的書架上都有一本 GoF！我在 Google 實習了兩次，***次的時候代碼全都是我一個人寫的，所以沒有使用任何 GoF 設計模式。代碼直接，精巧而簡單。當我第二次回到 Google，發現我的代碼里已經被加入了各種 factory，visitor，…… 其實啥好事也沒做，只不過讓我的代碼彎了幾道彎，讓人難以理解。
可見一本壞書，毀掉的不只是一代程序員。鑒于如此，特發此文。各位新手，希望你們敲響警鐘，不要再走上這條老路，寫出代碼來讓大家痛苦。
至于如何學會寫真正好的代碼，我在另一篇博文里再講。
