《設計模式》一書自1995年成書一來，一直是程序員談論的“高端”話題之一。許多程序員從設計模式中學到了設計軟件的靈感，或者找到了問題的解決方案。在社區(qū)中，既有人對模式無比崇拜，也有人對模式充滿誤解。有些程序員把設計模式視為圣經，唯模式至上；有些人卻認為設計模式只在C++或者Java中有用武之地，JavaScript這種動態(tài)語言根本就沒有設計模式一說。
　　那么，在進入設計模式的學習之前，我們最好還是從模式的起源說起，分別聽聽這些不同的聲音。
　　設計模式并非是軟件開發(fā)的專業(yè)術語。實際上，“模式”最早誕生于建筑學。20世紀70年代，哈佛大學建筑學博士Christopher Alexander和他的研究團隊花了約20年的時間，研究了為解決同一個問題而設計出的不同建筑結構，從中發(fā)現了那些高質量設計中的相似性，并且用“模式”來指代這種相似性。
　　受Christopher Alexander工作的啟發(fā)，Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides四人（人稱Gang Of Four ，GoF）把這種“模式”觀點應用于面向對象的軟件設計中，并且總結了23種常見的軟件開發(fā)設計模式，錄入《設計模式：可復用面向對象軟件的基礎》一書。
　　設計模式的定義是：在面向對象軟件設計過程中針對特定問題的簡潔而優(yōu)雅的解決方案。
　　通俗一點說，設計模式是在某種場合下對某個問題的一種解決方案。如果再通俗一點說，設計模式就是給面向對象軟件開發(fā)中的一些好的設計取個名字。
　　GoF成員之一 John Vlissides在他的另一本關于設計模式的著作《設計模式沉思錄》中寫過這樣一段話：
　　設想有一個電子愛好者，雖然他沒有經過正規(guī)的培訓，但是卻日積月累地設計并制造出許多有用的電子設備：業(yè)余無線電、蓋革計數器、報警器等。有一天這個愛好者決定重新回到學校去攻讀電子學學位，來讓自己的才能得到真實的認可。隨著課程的展開，這個愛好者突然發(fā)現課程內容都似曾相識。似曾相識的并不是術語或者表述的方式，而是背后的概念。這個愛好者不斷學到一些名稱和原理，雖然這些名稱和原理原來他不知道，但事實上他多年來一直都在使用。整個過程只不過是一個接一個的頓悟。
　　軟件開發(fā)中的設計也是如此。這些“好的設計”并不是GoF發(fā)明的，而是早已存在于軟件開發(fā)中。一個稍有經驗的程序員也許在不知不覺中數次使用過這些設計模式。GoF最大的功績是把這些“好的設計”從浩瀚的面向對象世界中挑選出來，并且給予它們一個好聽又好記的名字。
　　那么，給模式一個名字有什么意義呢？上述故事中的電子愛好者在未進入學校之前，一點都不知道這些關于電器的概念有一些特定的名稱，但這不妨礙他制造出一些電子設備。
　　實際上給“模式”取名的意義非常重要。人類可以走到生物鏈頂端的前兩個原因分別是會“使用名字”和“使用工具”。在軟件設計中，一個好的設計方案有了名字之后，才能被更好地傳播，人們才有更多的機會去分享和學習它們。
　　也許這個小故事可以說明名字對于模式的重要性：假設你是一名足球教練，正在球場邊指揮一場足球賽。通過一段時間的觀察后，發(fā)現對方的后衛(wèi)技術精湛，身體強壯，但邊后衛(wèi)速度較慢，中后衛(wèi)身高和頭球都非常一般。于是你在場邊大聲指揮隊員：“用速度突破對方邊后衛(wèi)之后，往球門方向踢出高球，中路接應隊員搶點頭球攻門�！�
　　在機會稍縱即逝的足球場上，教練這樣費盡口舌地指揮隊員比賽無疑是荒謬的。實際上這種戰(zhàn)術有一個名字叫作“下底傳中”。正因為戰(zhàn)術有了對應的名字，在球場上教練可以很方便地和球員交流�！跋碌讉髦小边@種戰(zhàn)術即是足球場上的一種“模式”。
　　在軟件設計中亦是如此。我們都知道設計經驗非常重要。也許我們都有過這種感覺：這個問題發(fā)生的場景似曾相識，以前我遇到并解決過這個問題，但是我不知道怎么跟別人去描述它。我們非常希望給這個問題出現的場景和解決方案取一個統(tǒng)一的名字，當別人聽到這個名字的時候，便知道我想表達什么。比如一個JavaScript新手今天學會了編寫each函數，each函數用來迭代一個數組。他很難想到這個each函數其實就是迭代器模式。于是他向別人描述這個函數結構和意圖的時候會遇到困難，而一旦大家對迭代器模式這個名字達成了共識，剩下的交流便是自然而然的事情。
　　學習模式的作用
　　小說家很少從頭開始設計劇情，足球教練也很少從頭開始發(fā)明戰(zhàn)術，他們總是沿襲一些已經存在的模式。當足球教練看到對方邊后衛(wèi)速度慢，中后衛(wèi)身高矮時，自然會想到“下底傳中”這種模式。
　　同樣，在軟件設計中，模式是一些經過了大量實際項目驗證的優(yōu)秀解決方案。熟悉這些模式的程序員，對某些模式的理解也許形成了條件反射。當合適的場景出現時，他們可以很快地找到某種模式作為解決方案。
　　比如，當他們看到系統(tǒng)中存在一些大量的相似對象，這些對象給系統(tǒng)的內存帶來了較大的負擔。如果他們熟悉享元模式，那么第一時間就可以想到用享元模式來優(yōu)化這個系統(tǒng)。再比如，系統(tǒng)中某個接口的結構已經不能符合目前的需求，但他們又不想去改動這個被灰塵遮住的老接口，一個熟悉模式的程序員將很快地找到適配器模式來解決這個問題。
　　如果我們還沒有學習全部的模式，當遇到一個問題時，我們冥冥之中覺得這個問題出現的幾率很高，說不定別人也遇到過同樣的問題，并且已經把它整理成了模式，提供了一種通用的解決方案。這時候去翻翻《設計模式》這本書也許就會有意外的收獲。
　　模式在不同語言之間的區(qū)別
　　《設計模式》一書的副標題是“可復用面向對象軟件的基礎”。《設計模式》這本書完全是從面向對象設計的角度出發(fā)的，通過對封裝、繼承、多態(tài)、組合等技術的反復使用，提煉出一些可重復使用的面向對象設計技巧。所以有一種說法是設計模式僅僅是就面向對象的語言而言的。
　　《設計模式》最初講的確實是靜態(tài)類型語言中的設計模式，原書大部分代碼由C++寫成，但設計模式實際上是解決某些問題的一種思想，與具體使用的語言無關。模式社區(qū)和語言一直都在發(fā)展，如今，除了主流的面向對象語言，函數式語言的發(fā)展也非常迅猛。在函數式或者其他編程范型的語言中，設計模式依然存在。
　　人類飛上天空需要借助飛機等工具，而鳥兒天生就有翅膀。在Dota游戲里，牛頭人的人生目標是買一把跳刀（跳刀可以使用跳躍技能），而敵法師天生就有跳躍技能。因為語言的不同，一些設計模式在另外一些語言中的實現也許跟我們在《設計模式》一書中看到的大相徑庭，這一點也不令人意外。
　　Google的研究總監(jiān)Peter Norvig早在1996年一篇名為“動態(tài)語言設計模式”的演講中，就指出了GoF所提出的23種設計模式，其中有16種在Lisp語言中已經是天然的實現。比如，Command模式在Java中需要一個命令類，一個接收者類，一個調用者類。Command模式把運算塊封裝在命令對象的方法內，成為該對象的行為，并把命令對象四處傳遞。但在Lisp或者JavaScript這些把函數當作一等對象的語言中，函數便能封裝運算塊，并且函數可以被當成對象一樣四處傳遞，這樣一來，命令模式在Lisp或者JavaScript中就成為了一種隱形的模式。
　　在Java這種靜態(tài)編譯型語言中，無法動態(tài)地給已存在的對象添加職責，所以一般通過包裝類的方式來實現裝飾者模式。但在JavaScript這種動態(tài)解釋型語言中，給對象動態(tài)添加職責是再簡單不過的事情。這就造成了JavaScript語言的裝飾者模式不再關注于給對象動態(tài)添加職責，而是關注于給函數動態(tài)添加職責。
　　設計模式的適用性
　　設計模式被一些人認為只是夸夸其談的東西，這些人認為設計模式并沒有多大用途。畢竟我們用普通的方法就能解決的問題，使用設計模式可能會增加復雜度，或帶來一些額外的代碼。如果對一些設計模式使用不當，事情還可能變得更糟。
　　從某些角度來看，設計模式確實有可能帶來代碼量的增加，或許也會把系統(tǒng)的邏輯搞得更復雜。但軟件開發(fā)的成本并非全部在開發(fā)階段，設計模式的作用是讓人們寫出可復用和可維護性高的程序。假設有一個空房間，我們要日復一日地往里面放一些東西。最簡單的辦法當然是把這些東西直接扔進去，但是時間久了，就會發(fā)現很難從這個房子里找到自己想要的東西，要調整某幾樣東西的位置也不容易。所以在房間里做一些柜子也許是個更好的選擇，雖然柜子會增加我們的成本，但它可以在維護階段為我們帶來好處。使用這些柜子存放東西的規(guī)則，或許就是一種模式。
　　所有設計模式的實現都遵循一條原則，即“找出程序中變化的地方，并將變化封裝起來”。一個程序的設計總是可以分為可變的部分和不變的部分。當我們找出可變的部分，并且把這些部分封裝起來，那么剩下的就是不變和穩(wěn)定的部分。這些不變和穩(wěn)定的部分是非常容易復用的。這也是設計模式為什么描寫的是可復用面向對象軟件基礎的原因。
　　設計模式被人誤解的一個重要原因是人們對它的誤用和濫用，比如將一些模式用在了錯誤的場景中，或者說在不該使用模式的地方刻意使用模式。特別是初學者在剛學會使用一個模式時，恨不得把所有的代碼都用這個模式來實現。錘子理論在這里體現得很明顯：當我們有了一把錘子，看什么都是釘子。拿足球比賽的例子來說，我們的目標只是進球，“下底傳中”這種“模式”僅僅是達到進球目標的一種手段。當我們面臨密集防守時，下底傳中或許是一種好的選擇；但如果我們的球員獲得了一個直接面對對方守門員的單刀機會，那么是否還要把球先傳向邊路隊友，再由邊路隊友來一個邊路傳中呢？答案是顯而易見的，模式應該用在正確的地方。而哪些才算正確的地方，只有在我們深刻理解了模式的意圖之后，再結合項目的實際場景才會知道。
　　分辨模式的關鍵是意圖而不是結構
　　在設計模式的學習中，有人經常發(fā)出這樣的疑問：代理模式和裝飾者模式，策略模式和狀態(tài)模式，策略模式和智能命令模式，這些模式的類圖看起來幾乎一模一樣，它們到底有什么區(qū)別？
　　實際上這種情況是普遍存在的，許多模式的類圖看起來都差不多，模式只有放在具體的環(huán)境下才有意義。比如我們的手機，把它當電話的時候，它就是電話；把它當鬧鐘的時候，它就是鬧鐘；用它玩游戲的時候，它就是游戲機。我看到有人手中拿著iPhone18，但那實際上可能只是一個吹風機。有很多模式的類圖和結構確實很相似，但這不太重要，辨別模式的關鍵是這個模式出現的場景，以及為我們解決了什么問題。
　　對JavaScript設計模式的誤解
　　雖然JavaScript是一門完全面向對象的語言，但在很長一段時間內，JavaScript在人們的印象中只是用來驗證表單，或者完成一些簡單動畫特效的腳本語言。在JavaScript語言上運用設計模式難免顯得小題大做。但目前JavaScript已成為最流行的語言之一，在許多大型Web項目中，JavaScript代碼的數量已經非常多了。我們絕對有必要把一些優(yōu)秀的設計模式借鑒到JavaScript這門語言中。許多優(yōu)秀的JavaScript開源框架也運用了不少設計模式。
　　J　　avaScript設計模式的社區(qū)目前還幾乎是一片荒漠。網絡上有一些討論JavaScript設計模式的資料和文章，但這些資料和文章大多都存在兩個問題。
　　第一個問題是習慣把靜態(tài)類型語言的設計模式照搬到JavaScript中，比如有人為了模擬JavaScript版本的工廠方法（Factory Method）模式，而生硬地把創(chuàng)建對象的步驟延遲到子類中。實際上，在Java等靜態(tài)類型語言中，讓子類來“決定”創(chuàng)建何種對象的原因是為了讓程序迎合依賴倒置原則（DIP）。在這些語言中創(chuàng)建對象時，先解開對象類型之間的耦合關系非常重要，這樣才有機會在將來讓對象表現出多態(tài)性。
　　而在JavaScript這種類型模糊的語言中，對象多態(tài)性是天生的，一個變量既可以指向一個類，又可以隨時指向另外一個類。JavaScript不存在類型耦合的問題，自然也沒有必要刻意去把對象“延遲”到子類創(chuàng)建，也就是說，JavaScript實際上是不需要工廠方法模式的。模式的存在首先是能為我們解決什么問題，這種牽強的模擬只會讓人覺得設計模式既難懂又沒什么用處。
　　另一個問題是習慣根據模式的名字去臆測該模式的一切。比如命令模式本意是把請求封裝到對象中，利用命令模式可以解開請求發(fā)送者和請求接受者之間的耦合關系。但命令模式經常被人誤解為只是一個名為execute的普通方法調用。這個方法除了叫作execute之外，其實并沒有看出其他用處。所以許多人會誤會命令模式的意圖，以為它其實沒什么用處，從而聯想到其他設計模式也沒有用處。
　　這些誤解都影響了設計模式在JavaScript語言中的發(fā)展。
　　模式的發(fā)展
　　前面說過，模式的社區(qū)一直在發(fā)展。GoF在1995年提出了23種設計模式。但模式不僅僅局限于這23種。在近20年的時間里，也許有更多的模式已經被人發(fā)現并總結了出來。比如一些JavaScript圖書中會提到模塊模式、沙箱模式等。這些“模式”能否被世人公認并流傳下來，還有待時間驗證。不過某種解決方案要成為一種模式，還是有幾個原則要遵守的。這幾個原則即是“再現”“教學”和“能夠以一個名字來描述這種模式”。
　　不管怎樣，在一些模式被公認并流行起來之前，需要慎重地冠之以某種模式的名稱。否則模式也許很容易泛濫，導致人人都在發(fā)明模式，這反而增加了交流的難度。說不準哪天我們就能聽到有人說全局變量模式、加模式、減模式等。
　　在《設計模式》出版后的近20年里，也出現了另外一批講述設計模式的優(yōu)秀讀物。其中許多都獲得過Jolt大獎。數不清的程序員從設計模式中獲益，也許是改善了自己編寫的某個軟件，也許是從設計模式的學習中更好地理解了面向對象編程思想。無論如何，相信對我們這些大多數的普通程序員來說，系統(tǒng)地學習設計模式并沒有壞處，相反，你會在模式的學習過程中受益匪淺。