對於模式的“十大誤解”（轉載）

誤解之一：“模式是某種場景下某個問題的解決方案”

這個定義來自於Christopher Alexander[AIS+77]，所以如果把它稱為“誤解”，也許有人會把我目為異端。但是下面這個簡單的反例就能讓你看清它的缺點：

問題：我獲獎的獎券就快過期了，我怎樣拿到獎金？
場景：離截止時間只有一小時，可是我家的小狗把獎券給吞了。
解決方案：把狗開膛破肚，掏出獎券，然後飛奔到最近的兌獎地點。

這是“某種場景下某個問題的解決方案”，但它不是模式。還缺了什麼？至少缺三樣東西：

1. 可重複性。解決方案應該對應於外部的場景。
2. 可傳授性。一個解決方案應該可以移植到問題的不同情況上。（絕大多數模式的可傳授性都建立在“約束”和“效果”的基礎上。）
3. 用來表示這個模式的名稱。

確實，很難找到一個令人滿意的定義。“模式討論”郵件列表（patterns-discussion@cs.uiuc.edu）上正在進行的討論也證明了這一點。難以定義的一大原因是：模式既是一個事物，也是對類似事物的描述。要區分這兩者，有一種辦法：“模式”這個術語只用來指代模式的描述，同時用“模式例項”來指代模式的具體應用。

但是，術語的定義很可能是白費力氣，因為一個定義可能對一個人（比如程式設計師）有意義，但是對另一個人（比如只能看到書面材料的專案主管）卻毫無意義。當然，我不打算在這裡提出什麼最終定義。但是，任何對模式要素的規定，除了必須包括問題、解決方案和場景之外，都必須提及可重複性、可傳授性和名稱。

誤解之二：“模式就是行話、規則、程式設計技巧、資料結構……”

我通常把這些誤解統稱為“蔑視”。如果你試圖把某些不熟悉的東西簡化為熟悉的東西，產生這種想法是很自然的，尤其是當你沒有特別的興趣去鑽研這些不熟悉的東西時。另外，某些人經常拿新瓶裝陳酒，然後大吹“創新”、“革命”一類的口號。保持警惕也是好的。

但是，這種蔑視通常不是來自親身體驗，而是來自膚淺的認識和一點點冷嘲熱諷的。而且，沒有什麼東西是真正“全新”的。人們的腦海中一直都存在著各種各樣的模式，只不過我們現在剛開始為模式命名、將模式記錄下來。

來逐個說明這些看法：的確存在著模式的行話，例如“模式”這個詞，例如“約束”，例如Alexander的“無名質量”，等等。但是模式是不能簡化為行話的。與其他電腦科學領域相比，模式引入的新術語實在是少得可憐。對於聽眾來說，好的模式本來就很容易接受。在說明一個模式的時候也許有必要引用問題領域的行話，但是幾乎沒有必要使用什麼特定於模式領域的術語。

沒有哪個模式是能讓你不假思索就使用的規則（元件則正好相反），同時模式也不僅僅是“程式設計技巧”，儘管模式中的“方言（idiom）”部分是特定於語言的。在我聽來，“技巧”這個詞帶有輕蔑的意思，並且過分強調解決方案，而忽視了問題、場景和名稱的重要性。

毫無疑問，你也曾經聽說過一次創新被接受的三個階段：首先，它被當作垃圾扔在一邊；然後，人們會認為它不具可實施性；最後，大家都明白它的意義時，它也沒有意義了――“我們一直都這樣做”。現在，模式還沒有完全走出第一個階段。

誤解之三：“理解一個，就理解了全部”

一刀切的規則往往是不公平的，而人們對模式卻更加一刀切。模式的領域、內容、範圍、形式、質量……這個領域大得嚇人，只需要隨手翻翻PLoP 的書[CS95, MRB98, VCK96]就能看出。不同的人寫出不同的模式，而模式的變化甚至比作者還要多。象Alistair Cockburn、Jim Coplien、Neil Harrison 和Ralph Johnson 這樣的作者已經超越了最初大量記錄不同領域、不同形式模式的階段。只看幾個例子就對模式做一個籠統的結論，這樣的結論必定是錯誤的。

誤解之四：“模式需要有工具或方法學的支援才會有效”

在過去的五年中，我記錄、使用並且幫助其他人使用模式，還至少幫助完成了一個基於模式的工具[BFV+96]，所以我可以很有把握的說：模式的絕大多數好處都來自於原封不動的使用――也就是說，沒有任何形式的外部支援。

在談到這個主題的時候，我通常會指出模式帶來的四大好處：

1. 它們記錄了專家的經驗，並且讓非專家也能理解。
2. 它們的名稱構成了一份詞彙表，幫助開發者更好的交流。
3. 它們幫助人們更快的理解一個系統――只要這個系統是用模式的方式描述的。
4. 它們使系統的重組變得更容易，不管原來的系統是否以模式的方式設計的。

過去，我一直認為第一項是模式最大的好處。現在我認識到，第二條起碼也同樣重要。請想一想，在一個開發專案的過程中，有多少位元組的資訊在開發者之間流動（包括口頭的和電子的）？我猜就算沒有1G也有好幾兆。（在推出了《設計模式》之後，我已經收到了好幾十兆給GoF的電子郵件。而且我們所描述的還都是小型到中型的軟體開發專案。）由於有如此之大的資訊交流量，所以效率上任何微小的提升都能大量節約時間。在這個意義上，模式拓寬了人們交流的頻寬。我對第三、四條的評價也在逐漸提高，特別是在專案越來越大、軟體生存週期越來越長的今天。

至少在短期內，模式主要存在於大腦中，而不存在於工具中。如果有了方法學或自動化工具的支援，應該還有其他的收益，但是我相信這些都只是蛋糕上的奶油，而不是蛋糕本身，甚至都不能算蛋糕的一層。

* * *

到目前為止，我說到的誤解都是關於“模式是什麼”的。現在來看看關於“模式可以做什麼”的誤解。這裡有兩種不同的風格：誇大其詞的和心存疑慮的。

誤解之五：“模式可以保證軟體的複用性、更高的生產力、世界的和平……”

道理很簡單，模式什麼都不保證。它們甚至有可能無法給你帶來利益。在創造新事物的過程中，模式無法取代人的位置。它們只是帶來一種希望，有可能讓一個缺乏經驗的、甚至是未入門的，但是有能力、有創造性的人儘快獲得設計的能力。

人們經常說：好的模式會讓讀者有“啊！”的回應。實際上，只有當模式恰好撥動了讀者的某一根心絃時，他們才會有這樣的反應。如果沒有，模式就只象森林裡普通的一棵樹。因此，什麼是好的模式？不管它寫得有多好，如果不能引起讀者的共鳴，它又怎能算是好的模式？

模式只是開發者的工具箱中的另一件工具，對模式寄以過高的期望只會適得其反。準備充分，然後做最壞的打算――這就是防止受騙、消除對抗最好的方法。

誤解之六：“模式可以‘生成’整個軟體體系”

這個誤解與上一個有點相似，不過侵略性稍微少些。

每過一段時間，模式論壇上就會討論一次模式的生成能力。按照我的理解，“生成能力”是指模式建立最終行為的能力。很多人認為，模式可以幫助讀者解決模式本身沒有明確提出的問題。我讀過的一些書裡也有同樣的觀點。

對於我來說，“生成能力”的關鍵是模式的可傳授性――約束及其解決，或者對於效果的討論。在你定義、精煉一個體繫結構時，這些觀察是特別有用的。但是模式本身並不製造任何東西――任何東西都是由人來製造的。而且，模式不可能覆蓋體系結構的每個方面。給我任何一個有實際價值的設計，我都能找出其中模式沒有涉及的設計問題。也許這些問題不常見、不具可重複性，或者只是還沒有以模式的形式記錄下來。不管怎樣，你都必須負責填補模式之間的空白――用你自己的創造性。

誤解之七：“模式是針對（物件導向）設計或實現的”

另一個極端則是過分的限制，就象這個誤解。坦白說，任何人都完全可能相信它，我不會有絲毫驚訝。無數的人問過我這個問題，所以它也進入了“十大誤解”之列。如果你覺得這種觀點實在天真幼稚，跳過這一部分吧。

如果模式不能記述專家的經驗，那它們就什麼都不是。對於模式的作者來說，任何形式的專家經驗都是可記載的。當然，在物件導向軟體設計中有值得記載的經驗，但是在非物件導向設計和分析、維護、測試、文件、組織結構……這些方面也同樣有值得記載的經驗。現在，不同領域中的模式開始浮出水面。至少已經有兩本關於分析模式的書[Fowler97, Hay96]，並且每次PLoP大會都會收到新的模式型別。（特別有趣的是1996年的PLoP大會甚至關注了音樂作曲的模式！）

和大多數的誤解一樣，這個誤解也是有原因的。看看人們用來描述模式的格式，有兩種基本的風格：描述高層結構的GoF風格（用於《設計模式》中）；接近文學的Christopher Alexander 風格――敘述性的，儘量少的結構圖。由於已經用模式描述了物件導向設計之外的東西，所以我現在認識到GoF風格造成的偏差。對於我研究過的某些領域的專家經驗，這種風格根本無法描述。為什麼結構圖看上去總是讓人聯想到C++？對於音樂作曲的模式，“實現”應該是什麼？“協作”部分真的有意義嗎？

很明顯，一種格式不能適應所有的需求。比較具有普遍意義的是模式的概念：模式是記載並傳達專家經驗的工具――不論是哪個領域的專家經驗。

誤解之八：“沒有證據表明模式幫助過任何人”

這種觀點曾經有一定的說服力，但是現在已經沒有了。在Software-Practice and Experience[Kotula96]這樣的雜誌上、在OOPSLA[HJE95,Schmid95]和ICSE[BCC+96]這樣的會議上，人們不斷的報告自己從模式得到的利益。Doug Schmidt已經清楚的說明了在傳授電腦科學時使用模式的收益[PD96]。儘管絕大多數的證據都只是定性的，但是據我所知，至少有一個組織得到了一些定量的結論[Prechelt97,PUS97]。

隨著時間推進，我們需要更好的掌握使用模式的好處和缺點。儘管最初的反饋已經讓我們看到了希望，但是我們還需要更多的實踐經驗來做全面的估計。但是，如果僅僅因為模式的好處還沒有完全證實就拒絕使用模式，那你就真的是個大傻瓜了。

* * *

關於“模式能幹什麼”的謬論還真不少。下面，最後兩種誤解不是關於模式本身，而是關於支援使用模式的人們的。

誤解之九：“模式社群是精英的小圈子”

我很想知道這種觀念到底是從哪裡來的。如果說模式社群的人們有什麼引人注目的地方，那就是他們之間巨大的差異。從PLoP大會的與會者名單就能看出――人們來自世界各地，有大公司的也有小公司的，有分析員、設計者和實現者，有學生也有教授，有大名鼎鼎的作者也有初出茅廬的菜鳥。更讓我驚訝的是，竟然有不少與會者都不是電腦科學工作者！這個社群仍然在不停變化，每年的與會者名單都與前一年不同。

如果將模式社群的背景公開出來，別人也許會覺得奇怪：很少有學院派人士。實際上，絕大多數PLoP的與會者都是實踐者。軟體模式早期的推崇者――包括Kent Beck、Peter Coad 和Ward Cunningham――都沒有學院背景。GoF中只有一個人（Ralph）是學院派，而且他也是我所認識的最實際的學院派。很明顯，模式社群從根本上反對任何可能的宗派主義和精英論。

誤解之十：“模式社群是自私的，甚至是陰謀家”

我不止一次的聽人指責說：模式最大的用處就是為寫模式書籍的人帶來了源源不斷的收入。他們甚至還暗示模式的發展有著某種邪惡的目的。

胡說八道！

作為GoF的一員，我可以肯定的告訴你：對於《設計模式》引起的反響，我們和其他任何人一樣吃驚。對於它在OOPSLA 94上的初次亮相引起的暴風驟雨，我們也同樣沒有準備――甚至出版商都沒有預料到會有這麼大的銷量。在整個寫作過程中，我們最關心的就是儘量寫出一本高質量的書，至於銷售上的問題，我們根本沒有時間去想。現在“模式”已經成了一個時髦的詞彙，不可避免的會有一些人將這個詞用來謀取私利。但是，如果你認真讀過頂尖的模式作者的作品，你就會感覺到他們共同的目標：將難以獲取的經驗、最佳的實踐、甚至是競爭中的優勢――多年實踐經驗的累積――分享給讀者，而且講解得一清二楚。正是這種幫助讀者的熱情激勵著每一個真誠而踏實的模式作者。如果沒有這種熱情，作者就會弄巧成拙――這種不負責任的作者往往正是對模式所有誤解的根源！