設計模式，1994年生，2034卒

前言

本文是2194年“程序員考古年會”的壓軸發言稿，三年前，一支考古隊在機房遺址發現了一本墊在顯示器下的殘書，經過AI恢復以后，驚喜地發現了一門早已失傳的技術：設計模式，從此掀起了一股設計模式考古熱潮。

黑暗時代

上世紀七八十年代，軟件開發更像手藝活，每個人都有自己的工具、習慣和“祖傳寫法”。

最開始程序規模不大，幾千幾萬行代碼，一個人還能掌控。

很快軟件開始膨脹，幾十人協作、幾十萬行代碼的大項目出現了。

于是，Smalltalk、C++、Objective-C 等語言陸續登場，希望用面向對象解決復雜性。

今天的人們已很難準確理解“面向對象”為何物，但根據殘存的技術博客，考古人員推測它是一種把世界萬物都看作“東西”的信仰。

但程序員卻發現，這些編程語言提供了磚頭，卻沒告訴你房子該怎么蓋。

如果解耦對象？如何減少依賴？如何讓系統容易擴展？怎么才能在變化中活下來？

類似的難題困擾著無數的程序員。

當時互聯網不發達，交流少，大家不斷地在重復發明輪子。

考古顯示，舊金山的馬丁為了“對象變化后如何通知其他對象”，苦思數周，終于找到一種優雅結構。 與此同時，在遙遠的德國，漢斯也發明了幾乎一樣的東西。

這樣的事情越來越多，終于讓隱居在代碼深淵里的高手皺起了眉頭，決定出手收拾局面。

暗號

1990年，在一個面向對象的會議上，來自瑞士Erich Gamma 遇到了來自澳大利亞的Richard Helm，兩人聊著聊著，赫然發現：“等等……你研究的，怎么跟我研究的一樣？”

他倆都在參考建筑行業（門為什么放在這里？窗戶為什么這么設計？城市為什么形成街區....），試圖總結軟件設計中的共性問題。

那還等啥，趕緊合作吧。

后來，來自美國的John Vlissides 和Ralph Johnson 也加入了他們。

當時沒有Git、沒有Zoom，沒有Google doc，Slack ，Notion...... 更沒有現在的“AI集體思考環境”。

四個人分散在三個國家，全靠郵件進行交流，偶爾在OOPSLA這樣的大會上碰頭兒。

考古人員努力整理了四位作者的往來郵件，其中一封的標題是“關于第三個模式的第七次修改意見”，正文長達四十頁，附帶了十一個 UML 圖。 現在很難理解 UML 究竟是一種語言還是一種儀式，考古人員猜測那些方框和箭頭大概是用來在寫代碼之前消耗過剩熱情的。

四人就像植物學家，努力地整理著黑暗森林的植物，辛苦勞作了4年以后，常見的23種設計終于被分門別類地整理了出來。

1994年，一本封面普通，甚至有些沉悶的書出版了，書名極其克制：《Design Patterns: Elements of Reusable Object-Oriented Software》。

后來，程序員們懶的念全名，直接叫它《設計模式》，四位作者也被稱為GoF(四人幫）

“GoF”本意是 Gang of Four，被一位華裔程序員譯成“四人幫”后在中國程序員圈子里極具辨識度，雖然這個稱呼偶爾會引發歷史老師與軟件工程師之間的尷尬誤會。

這可能是軟件歷史上最奇怪的一本書，它沒有發明編程語言，操作系統，數據庫，只是做了一件事情：把程序員已經在做的事情，命名了。

但命名本身就是一種力量，它變成了一種語言，一種程序員之間的暗號。

只要有人說：這里用Strategy”，所有人立刻就會明白：

• 動態切換算法

• 接口統一

• 行為可替換

黃金時代

不得不說，設計模式碰上了好時候。

1995年到2010年，企業級軟件進入地獄級復雜度，面向對象成為主流信仰。

“企業級”是一個至今未能完全破譯的修飾詞，考古人員從大量招聘廣告殘片中推斷，它大體意味著“更貴、更慢、但讓人更有面子”。

無數程序員虔誠地相信：世界可以被抽象成 class

設計模式的出現，又可以把這些class漂亮地組織起來，讓無數人沉迷其中，無法自拔。

C++老當益壯，Java迅猛崛起，那冗長的語法和設計模式簡直是絕配。

程序員開始像背元素周期表一樣背模式，Singleton，Factory，Observer，Decorator，Facade，Visitor，Strategy，Builder，Template Method......

設計模式成了面試必問的知識點：“請解釋一下Observer Pattern。” “你什么時候會使用Factory？”

甚至出現了“Singleton的七種寫法是什么”這樣的離譜問題。

據考證，這曾是一道用于折磨候選人的著名酷刑，其確切用意已不可考。

程序員們不懂設計模式，會被同事鄙視，有些人甚至相信，不使用設計模式的代碼，不夠專業，不能提交。

以GoF的《設計模式》為核心，出現了無數的周邊產品：

《Java與設計模式不得不說的故事》、《戲說設計模式》、《趣味設計模式》、《頭大設計模式》、《張大胖與設計模式》......

一個奇怪的時代來了，設計模式從“經驗總結”，升格為一種亞文化、一種信仰、一種身份標簽。

甚至出現了一種新型程序員，他們寫代碼之前會先問一句：這里適合什么Pattern？

這導致了一個Hello World都變得復雜無比：

}

第一次危機

編程語言開始飛速進化，Java 8引入了Lambda表達式和Stream API，C，Scala、Kotlin在JVM上玩起了函數編程和類型安全的魔法。

框架開始接管世界，Spring，Hibernate，Django，Rails，React，Angular，Vue......

很多設計模式被編程語言和框架吃掉，突然變得不需要親自手寫了。

比如策略模式，曾經程序員需要寫一個策略接口再加一堆實現類，現在Lambda表達式幾行解決，策略模式“縮水”成了函數式接口和一行函數體的組合。

函數式編程的大旗越舉越高，它的支持者給出的理由極其簡練：你的OOP設計模式在我這里，很多時候根本就不叫“模式”，只是“語言特性”。

設計模式沒有消失，它只是被藏起來了，就像地下管道，你看不見，但它仍然存在。

今天挖掘出的 Spring 框架遺址顯示，其內部布滿了這種“管道”，但當時的使用者只需打個注解，完全忘了它們的存在。

很多年輕程序員開始產生一種錯覺：我從來不用設計模式，也活得好好的啊。

值得注意的是，GoF的成員之一Erich Gamma加入了微軟，開發出了Visual Studio Code這個現象級的編輯器，這本身就是一個巨大的隱喻：一個靠設計模式成名的程序員，最后選擇去做開發工具，而不是繼續推廣模式。

但暴風雨真正來臨，是在更晚些時候。

死亡

2023年之后，AI進入軟件開發，開始自動生成代碼，自動補全，自動重構。

年輕程序員他們忙于學習如何拆分任務，審查AI輸出，管理上下文， 很少再讀GoF了。

面試也變了，過去要求“解釋一下Builder Pattern”，現在是“你如何讓AI穩定生成可維護代碼？”

設計模式逐漸成為一種舊時代的術語，像匯編優化，手寫內存管理，不是沒人懂，而是越來越少人主動接觸。

2034年，最后一本以“設計模式”為主題的技術書籍停止出版，同年，計算機科學核心課程中移除了“設計模式導論”課程。

設計模式死亡，享年40歲。

考古發現，在設計模式的最后幾年，全球還有最后一小群“模式狂熱愛好者”（他們大多是上了年紀的軟件架構師），在Reddit的r/DesignPatterns子版塊里發表著最后的嘆息與懷舊： “1998年，讀完GoF書的那一天，我看整個軟件的視角都變了！” “看完Jive源碼，我第一次感受到軟件竟然可以如此美妙！”

但新入行10后程序員們對此無動于衷。他們用自然語言指揮AI寫CRUD，然后懶洋洋地甩一句：“設計模式，那是什么鬼東西？”

設計模式的幽靈

2045年，清北大學的AI研究團隊在調試一個多智能體系統時，發現了一些令人瞠目結舌的現象：

這些AI智能體，自發演化出了一套類似“設計模式”的結構！

比如，當系統需要動態選擇不同方案時，主控Agent不會直接決定執行路徑，而是把任務交給一組“策略Agent”。

每個Agent負責一種實現方式：有的擅長性能優化，有的偏向穩定性，有的優先考慮資源成本。主控Agent根據上下文自動切換調用對象：這不就是Strategy Pattern嘛!

當某個Agent無法處理請求時，它會把請求自動轉交給另一個更適合的Agent。若第二個仍無法處理，則繼續向后傳遞，整個過程沒有中心調度，只有一條不斷傳遞責任的鏈路：Chain of Responsibility。

除此之外，研究人員還觀察到了：Builder模式，Template Method， Observer......

最令人不安的是，沒有人教過AI這些模式，沒有一本《Design Patterns》被輸入訓練數據，這些結構并不是被學習，而是被“重新發明”。

研究團隊最終把這些模式整理成了論文，發表于《自然·機器智能》雜志，標題是：

《模式的模式：人工智能智能體如何重新發現1994年的設計思想》

論文最終給出了一個非常讓人深思的結論：當AI系統擁有足夠復雜的任務和自治能力時，它最終會收斂到與人類工程設計相同的底層抽象，某些組織方式，會不可避免地再次出現。

就像就像橋梁最終會長成拱形，城市最終會出現道路，復雜系統最終會重新發明秩序。

這一結論也引發了一個意外的哲學爭論：設計模式到底是人類的發明，還是數學般先驗存在的規律？ 這場爭論成為21世紀最有爆炸性的學術懸案之一。