设计模式，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都变得复杂无比：

// 抽象产品interface Message {    String getText();}// 具体产品class HelloWorldMessage implements Message {    public String getText() {        return "Hello World";    }}// 工厂模式interface MessageFactory {    Message createMessage();}class HelloWorldFactory implements MessageFactory {    public Message createMessage() {        return new HelloWorldMessage();    }}// 单例模式（控制输出器）class OutputManager {    private static OutputManager instance;    private OutputManager() {}    public static OutputManager getInstance() {        if (instance == null) {            instance = new OutputManager();        }        return instance;    }    public void print(Message msg) {        System.out.println(msg.getText());    }}// 主程序public class Main {    public static void main(String[] args) {        MessageFactory factory = new HelloWorldFactory();        Message msg = factory.createMessage();        OutputManager output = OutputManager.getInstance();        output.print(msg);    }}

第一次危机

编程语言开始飞速进化，Java 8引入了Lambda表达式和Stream API，C#早就有了委托和LINQ，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世纪最有爆炸性的学术悬案之一。