GoF 23 种设计模式，一半在 Python 里直接消失了
兄弟们，今天来聊个可能得罪人的话题：设计模式，其实很烂。
别着急喷，先听我说完。
一、设计模式是怎么来的？
在软件工程里，"设计模式"这个词被说烂了。说实话这词有点冗余——难道还有不是"设计"出来的模式？
这个概念最早来自建筑学——是真的建筑学，盖房子画图纸那种，不是软件架构。
但1994年，软件界有了自己的版本：Gamma、Helm、Johnson、Vlissides 四个人（人称"四人帮"GoF）出了本《设计模式》，介绍了23个经典模式，说是比函数调用更高层的抽象，语言无关，可复用，用来解决 recurring 的软件设计问题。
听起来挺好是吧？好得有点不真实……
问题是：设计模式已经从"有用的词汇表"被捧成了近乎教条的东西。
它们被当成万能解来教，被用在根本不需要的地方，被当作"优秀工程"的标志。
但现实是：设计模式很烂。
对，我就是这么说了。
设计模式被高估了、被滥用了、而且很多时候完全没必要。
这话可能有点刺耳，尤其是那些把 GoF 的书放枕头边的兄弟们。但你想想：大多数时候，设计模式不过是一些丑陋的 workaround——因为我们的编程语言不够强大、不够灵活，表达不出我们真正想要的东西。
二、Java 和它的模板代码虐恋
拿 Java 举例子吧（今天我要黑 Java 挺多的，做好心理准备）。
从哪说起呢？Java 就是"设计模式狂热"的典型代表。每个 Java 项目长得都跟复制粘贴的一样——因为 Java 开发者被教的就是：能塞多少模式就塞多少。
Java 这门语言，几乎是逼着设计模式成了主流。为啥？因为 Java 啰嗦、僵硬、缺乏表达力。
就像写小说只允许用三音节词——每个问题都感觉比实际难十倍。
哦，你在写一个简单的 CRUD 应用？
那得整个 Factory 吧？数据库变更通知得整个 Observer 吧？还有 Singleton 别忘了——毕竟大家都需要全局 logger 对吧？
💡 冷知识：Singleton 模式 95% 是用来写日志的，剩下 5% 是用来在并发程序里制造问题的。
三、模式 vs 语言特性
设计模式为啥大多是垃圾？核心原因：它们存在只是因为语言本身缺功能。
你本质上是在给语言的局限性打补丁。
拿 Singleton 举例子，你见过一千遍了：
public class Logger {
private static Logger instance;
private Logger() {}
public static Logger getInstance() {
if (instance == null) {
instance = new Logger();
}
return instance;
}
}
就为了说一句"我只想要一个实例"，写了15行代码。
我们是原始人吗？这种事不该需要手写。现代语言应该提供优雅的语法来处理，但 Java 不行。
于是我们得到了一大堆模板代码和复杂度，还美其名曰"最佳实践"。
想看看 Scala 怎么处理吗？
object Logger
没了。整个 Singleton 模式就这。完了。
不用折腾什么静态块、线程安全、懒加载那些破事。Scala 做了 Java 本来就该做的事：把这当成基础语言特性，而不是需要你手动实现的模式。
Java 逼你写 Strategy 模式，是因为它没有一等公民函数。这是语言的锅，不是你的。
设计模式不是在解决你代码的问题，它们是在解决你语言的问题。
Factory 模式？那就是 Java 不肯给你像样的构造器，不肯原生支持复杂对象创建。在 Python、Ruby、Scala 这些语言里，你几乎不需要 Factory。
事实上，Java 开发者津津乐道的大部分设计模式，在更灵活、更有表达力的语言里，直接就消失了。
拿 Python 举例：
- • 需要 Factory？传个函数就行，或者聪明点用
__init__ - • 想要 Singleton？整个模块，或者初始化一次的类，完事
- • Observer？函数是一等公民，传来传去就完了
事实就是：在表达力足够的语言里，模式要么变得 trivial，要么——更好——根本就不存在。
你直接解决问题，而不是把问题包进20年前某个人用一门已经过时的语言想出来的抽象里。
💡 在 Lisp 里，你可以重写任何语法结构的行为。模式在那里根本没扎根——你写个宏，语言就听你的了。
四、过度工程的邪教
设计模式还助长了软件界一个更深的问题：过度工程。
我见过初级工程师（不幸的是还有一些高级的），一听到"设计模式"眼睛就亮了，然后立刻想办法把尽可能多的模式硬塞进项目里。
他们在解决想象出来的问题。
这种事一旦发生，代码库就从"能看懂"变成"读不懂、脆弱、过度抽象"。
它变成了一个由接口、工厂方法、奇怪命名约定组成的迷宫——感觉像在解读古代文献。
💡 你怎么知道自己在写 Java？当仓库里80%的文件都是接口，这些接口又实现了别的接口，啥也不干就把调用往更远的地方扔。
"好的"设计模式往往是过度工程的，因为它们需要迎合尽可能多的用例。但过度工程的代码是有代价的：你得读它、理解它、理解它在整个系统里怎么工作。
所以，跟任何其他软件开发技术一样，你得评估使用这项技术的成本，判断收益是否超过成本。
不是每个问题都需要设计模式。事实上，大多数问题都不需要。
通常最简单、最直接的方案就是对的。
经验法则：如果你的方案需要画图才能解释，那你就走太远了。
五、设计模式真正有用的地方
说句公道话，模式最诚实的价值是：给一个大想法起个短名字。
在团队里，说"这是个 facade"比每次都解释"我们为啥把三个类藏在一个包装器后面"要容易。
就这个。这才是真正的用途。
模式不是用来教你写好代码的。它们是用来讨论已经写好的代码的。
这样你可以问"这个类是啥？"，然后听到"哦，这是 mediator 的一部分"。而不是疯狂对照 UML 图想"我这里该套哪个模式？！"
一个理解了底层概念——关注点分离、封装、组合优于继承——的开发者，自然会写出干净的代码，哪怕他们从没听过"Singleton"这个词。
模式不过是给好开发者本来就会做的事贴的标签。
我在好几家最大的科技公司工作过。没人日常用这些词，我面试时也从没被问过（要是被问了，对我反而是个危险信号）。
六、Gosling 哲学 vs Guido 哲学
DHH 有段话说得特别好，精准解释了 Java 为啥变成这样。
Java 的设计者 James Gosling 对程序员的看法很悲观。他的前提是：给普通开发者太多权力，他们会开枪打自己的脚。
所以 Java 被建成了一个沙盒——保持僵硬、保持安全、别让他们伤到自己。
这对写得用20年的中型保险公司代码来说挺好。但对表达力来说，就不怎么样了。
Guido van Rossum 设计 Python 时走了完全相反的路。他的前提是：代码读的次数比写的多，所以优化可读性，给程序员真正的工具。
一等公民函数、装饰器、上下文管理器、鸭子类型——Python 给你积木，让你直接解决问题，而不是把所有东西都通过类层次和接口仪式来传递。
设计模式是 Gosling 世界的解决方案。
它们存在是因为语言不信任你能直接解决问题。
在 Guido 世界的语言里，你就……直接解决。
设计模式是一个时代的遗物——那个时代语言还不够有表达力。
GoF 的模式有一半在 Python、Ruby、Scala 里直接消失了，这说明一切——它们从来就跟"设计"没关系。它们跟"语言别挡你的路"有关系。
📝 总结一下
- 1. 设计模式大多是语言不够强的 workaround，不是什么高级智慧
- 2. Java 是重灾区，因为语言表达力差，逼得你用各种模式
- 5. 学底层概念比背模式重要：分离关注点、封装、组合优于继承
下次有人跟你扯"这里该用什么设计模式"的时候，先问问自己：
这个问题真的需要模式吗，还是只是语言不够好用？
原文作者：luminousmen
发布时间：2026年6月8日
原文链接：luminousmen.com/post/design-patterns-suck
10个月宝宝每天需要喝多少奶粉？
