本文首次發布在IEEE軟件雜志，由InfoQ和IEEE計算機社會為您呈現。
在軟件開發中，好的建議是可遇不可求的。通用設計原則可以指導我們，但現實總是逼著我們，在看起來相互沖突的目標之間妥協，比如，可擴展性和可維護性與規模和復雜性。同樣的，現有代碼庫可以在很大程度上讓我們避免重復造輪子，但想要初級開發者輕松組合那些現有組件來做項目，依然不現實。
設計模式幫助我們縮小了這種差距：對特定情形下重復出現的問題，它記錄了不錯的解決方案。設計模式討論影響方案設計的主要因素，而不提供現成復制粘貼的代碼片段。Web應用的性能和安全就是這樣的例子：加解密算法增強了安全性，但引入了處理開銷。就如你兄長教你如何做正確的事情一般，Ward Cunningham曾經描述了最佳的設計模式。1
盡管模式很流行，但作為設計手法的影響，比作為特殊的軟件產品的影響更加難以定量描述。本文主要闡述了模式匯編會議20年后，可用模式的廣泛性和部分模式對開源軟件的影響深度。
模式起源
受建筑師和哲學家Christopher Alexander啟發， 在1987年，Kent Beck和Ward Cunningham共同編寫了設計Smalltak窗口程序的小模式語言。1993年，Beck和Grady Booch發起的一次科羅拉多山區度假，發展成了非盈利性Hillside組織。而該組織通過一系列的PLoP（編程模式語言大會），推動了模式匯編工作。PLoP已成功舉辦了20年，在這個過程中，誕生了很多成功的模式論文和書籍。
1994年，Erich Gamma和他的同事合著的《設計模式》一書，把模式的概念宣傳給更廣泛的人群；到目前為止，該書已經以13種語言，賣出了50萬本。2兩年以后，Frank Buschmann和他的同事合著了《面向模式的軟件架構》系列3第一卷；緊接著，Martin Fowler出版了他的《分析模式》。4（深入閱讀的資料可在別處獲取。5-9）“模式形式”的成功，甚至令一些作者和出版商無故給書的標題上加上“模式”二字，我們覺得這是成功的代價。2013年的亞馬遜網站上，在計算機和技術類圖書中，搜索關鍵詞“模式”，結果產生了超過5500個不同的條目（包括少數不相關的視覺模式檢測條目）。
圍繞模式的早期炒作已經塵埃落定，人們意識到，模式既不能代替設計技巧，也不能解決所有問題。盡管如此，根據實際經驗精心提煉的模式，能提供很有價值的相關建議。因為現做現學，往往不是現實項目的可選項，而模式提供了學習別人經驗的一種方式。
沒有模式疲勞的跡象
模式領域的普遍多樣性，使得有記載的模式的數目很難確定。Linda Rising的《模式年鑒2000》列出了超過1000種模式。10由Hillside組織贊助的PLoP大會已經接受了超過1500篇模式論文。大會論文的提交率一直穩定在每年100份左右。保守估計每篇論文4種模式，再加上所有的書籍和封面設計，移動應用開發，自適應系統，可持續架構，領域特定模式，元架構，工作流，容錯系統和安全。
大多數人認可的模式定義為：特定上下文中，某問題的成熟解決方案。在《建筑的永恒之道》中，Christopher Alexander闡明道：“簡而言之，模式是，在同一時間，世界上發生的事物，創建這個事物的規則以及必須創建該事物的時刻。”11模式給出了可復用的解決方案，也提供了方案的好處和它的權衡，并封裝了成熟的最佳實踐的知識。
例如，很多集成體系架構都使用Broker模式，它扮演客戶端和服務端中間人的角色，負責處理消息路由，包括序列化和反序列化消息內容。2Web的通訊基礎架構就實現了這種模式；類似YAWL的工作流引擎也包含了豐富的實現。12
很多模式只是模式庫的一部分，例如雅虎的UI庫和安全模式網站。很多公司，包括亞馬遜，谷歌，IBM，Lucent，微軟，甲骨文和西門子，都寫有相似的模式集合，它們中的部分可從書籍或網站獲取。IBM的電子商務分類編目模式就是模式集合的一個例子，除許多其他重復設計外，WebSphere產品系中的ESB（企業服務總線）實現還以它為特色。13基于彼此構建的、相互關聯的模式的集合可形成模式語言，它能支撐具有生產力的，領域特定的開發過程。14甚至還有一個編寫模式的模式語言。15
企業集成模式
模式在軟件架構和設計上的成功，激勵了人們嘗試把它們更緊密的集成到編程工具中以提高生產力，更緊密的整合進設計和實現的思維方式中。不幸的是，大部分嘗試都失敗了，因為模式原本只是人類之間記錄和傳遞知識的媒介，不是一個編程結構。盡管如此，有些模式語言確實直接影響了軟件方案的建立過程。
大約在2003年，ESB這個術語，由于描述SOA（面向服務的體系結構）集成平臺獲得了人們的關注。ESB產品在不同服務之間路由、過濾和轉換XML消息；它們代表的是實現Broker模式的傳統企業應用集成產品的演變。諷刺的是，盡管ESB產品的目標是整合不同的企業應用，但是缺乏描述這種方案設計的共同詞匯。
圖1 Apache Camel核心代碼隨時間增長情況。Java代碼庫的線性增長意味著穩定的提交者社區和可持續的發展。JavaScript的代碼量在2009年跳躍式增長之后，開始放緩；同樣的情況也發生在JavaScript類庫和框架的可用性上。
開源ESB實現的開發者們想要填補這種空缺，但很快就發現，EIP（企業集成模式）提供了從集成風格到消息路由和轉換的、條理清楚的65個模式詞匯7。而這些詞匯能夠描述大部分有意義的ESB解決方案。因此，在缺乏ESB工業標準的情形下，開源項目把EIP詞匯作為了事實上的標準。
開源ESB產品
在2005年，隨著開源ESB產品的出現，幾乎有一打的開源ESB產品，已經在它們的產品級領域特定語言或編程模型中，嵌入了EIP語言。最廣泛使用的例子有Mule，Apache Camel，WSO2 ESB，Spring Integration和OpenESB。
開源項目的性質使得跟蹤它的代碼量相對容易很多。但是，跟蹤市場占有率卻相對比較困難，因為銷售數據并不存在，下載次數也被鏡像站點、緩存或者自動下載所扭曲。13Apache Camel包含大約89萬行代碼，由62個提交者，6年時間，18000次個人提交所創建。Java代碼庫一直呈現驚人的線性增長（圖1），這意味著穩定的提交者群體始終如一的參與。在開源核心部分的商業版本（如Red Hat版，Talend版）中，添加的設計或運行時管理工具也顯著的擴大了代碼庫。
Apache Camel由Maven Central提供的下載量平均每月大概25000次，2013年7月達到峰值，超過30000次。這個數字高于YAWL，它的下載量在2010年大約每月1000次。13Mule報告說，在它的官方站點有360萬次下載，但并不能說明這都是由個人用戶發起的下載。
社區參與給開源的成功提供了另外一個深刻的度量。Apache Camel在2007年首次發布后，它的社區發帖量呈直線上升，穩定在每月大概2500貼。這表明它是一個協作解決問題和促進產品演變的健康社區。與此相比，Mule社區首頁顯示，它擁有15萬成員，但論壇發帖總量卻只有26600。
作為設計工具的模式
融入產品的EIP詞匯流行開來之后，有些ESB項目更進一步，在他們的設計工具中，采用EIP模式骨架作為其中的可視語言。例如，在Redhat Fuse集成開發環境或Mule Studio中，開發者可以使用EIP圖標語言。跟以前不同，對異步消息解決方案的簡單管道過濾器架構風格，努力“可視化編程”的嘗試，使這種可視化模式組合顯得很自然。圖2顯示了可視化的Camel路由：它通過消息路由器，把傳入的消息轉發給兩個可能的消息端點之一。現在，ESB開發者可以使用EIP詞匯來思考、設計、交流和實現他們的解決方案。
圖2 在Redhat Fuse集成開發環境中，使用EIP7中可視化模式語言創建消息解決方案。消息從基于文件的消息端點發出；在基于內容的路由器中，根據消息內容所指明的城市，轉發給兩個消息端點之一。基于內容的路由器模式，描述了一種可復用設計：根據消息內容，把消息路由給正確的接受者。
圖3 玩印有EIP的撲克。可視化模式語言允許交互式的、近乎好玩的模式用法。每張牌上都印有模式圖標、名稱和解決方案。
在首屆CamelOne大會上贈送的EIP撲克牌（圖3），可能是迄今為止最有創意的模式改編了。每張牌上都印有模式語言中的一個模式和方案陳述。很高興能看到，為增進人們交流和合作而創建的設計模式，能以這種平易近人的、有用方式來到架構師和工程師的手中。
我們以上介紹的統計數據表明，在過去的20年里，模式語言對軟件設計社區有著廣泛的影響。然而，很多模式研究的問題都還沒有答案。例如，好的模式并不總是那么容易找到，它需要做更多的工作，去組織和分類大量現有模式。我們還設想，也許使用語義維基技術，模式語言能夠制作工具。最終，以模式為中心的設計工具，能保證比單純的組件和連接器的畫圖工具，對軟件工程師更有吸引力。
模式社區會失去動力嗎？我們不這樣認為：現存的模式語言，就像EIP一樣，將會繼續被實現為領域特定語言。而沒有發現模式的領域還依然存在。例如，應用之間（通過技術協議）和人類之間（如通過社交網絡）的典型會話，都應能以模式的形式予以保存。模式的未來是光明的，我們誠邀您來塑造它，不管是通過促進模式工具的開發，還是以模式的形式，書寫和分享您的設計智慧。
參考
1. W. Cunningham, “Tips for Editing Patterns,” Dec. 2002.
2. E. Gamma et al., Design Patterns, AddisonWesley Professional, 1994.
3. F. Buschmann et al., PatternOriented Software Architecture, Volume 1: A System of Patterns, John Wiley & Sons, 1996.
4. M. Fowler, Analysis Patterns: Reusable Object Models, AddisonWesley Professional, 1996.
5. J. Kerievsky, Refactoring to Patterns, AddisonWesley Professional, 2004.
6. M. Fowler, Patterns of Enterprise Application Architecture, AddisonWesley Professional, 2002.
7. G. Hohpe and B. Woolf, Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, AddisonWesley Professional, 2004.
8. E. Evans, Domain Driven Design: Tackling Complexity in the Heart of Software, AddisonWesley Professional, 2003.
9. V. Vernon, Implementing DomainDriven Design, AddisonWesley Professional, 2013.
10. L. Rising, The Pattern Almanac 2000, AddisonWesley, 2000.
11. C. Alexander, The Timeless Way of Building, Oxford Univ. Press, 1979.
12. M. Adams, A.H.M. ter Hofstede, and M. La Rosa, “Open Source Software for Workflow Management: The Case of YAWL,” IEEE Software, vol. 28, no. 3, 2011, pp. 16–19.
13. M. Keen et al, Patterns: Implementing an SOA Using an Enterprise Service Bus, IBM, 2004.
14. F. Buschmann, K. Henney, and D. Schmidt, “Past, Present, and Future Trends in Software Patterns,” IEEE Software, vol. 24, no. 4, 2007, pp. 31–37.
15. G. Meszaros and J. Doble, A Pattern Language for Pattern Writing, Hillside Group.
關于作者
Gregor Hohpe是Allianz SE的首席企業家構師和Hillside組織的成員。郵箱：info@enterpriseintegrationpatterns.com。
Rebecca WirfsBrock是WirfsBrock Associates的主席和Hillside組織的財務主管。郵箱：rebecca@wirfsbrock.com。
Joseph W. Yoder是The Refactory公司和Hillside組織主席。郵箱：joe@refactory.com。
Olaf Zimmermann教授是位于Rapperswil的Eastern Switzerland大學應用科學系Institute forSoftware機構的研究合作伙伴。郵箱：ozimmerm@hsr.ch。
本文首次發布在IEEE軟件雜志。IEEE軟件的任務是創建領先和未來的軟件從業人員社區。該雜志提供準確、實用、前沿的軟件開發信息，以確保工程師和管理人員掌握快速變化的技術。
原創文章，轉載請注明： 轉載自Let'sCoding.cn
本文鏈接地址: 模式影響之20年