本博客日IP超过2000，PV 3000 左右，急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包，请加博主新的微信号：xttblog2，之前的微信号好友位已满，备注：返现
受密码保护的文章请关注“业余草”公众号，回复关键字“0”获得密码
所有面试题(java、前端、数据库、springboot等)一网打尽，请关注文末小程序
【腾讯云】1核2G5M轻量应用服务器50元首年，高性价比，助您轻松上云
Java 成了设计模式的重灾区！
是的，你没看错，这是老外最近讨论很火的一件事。Java 程序员深受其苦，尤其是在面试的时候，设计模式在面试中被问到的概率非常高。然而，有老外却说：“设计模式，真的被高估了”。
写代码，还是写设计模式？
在软件工程领域，“设计模式”这个词被用得有点泛滥了。说实话，这个词本身就挺冗余的，“设计”和“模式”有什么区别？所有模式不都是设计出来的吗？
程序员常说的设计模式最初来自建筑学，就是盖房子那种真正的建筑学。但在 1994 年，软件行业有了自己的“圣经”。Gamma、Helm、Johnson 和 Vlissides 四人合著的《设计模式》，江湖人称“GoF”（Gang of Four，四人帮）。他们在书里提出了 23 种经典模式，号称是解决常见软件设计问题的通用模板，而且跟编程语言无关。
听起来很美好，对吧？
但事实是设计模式被高估了、被滥用了，而且很多时候根本就是多余的。
这话虽然有点刺耳，特别是那些把 GoF 的书放在枕边的朋友。但你耐心认真的思考想象一下，你可嫩就会发现大多数设计模式，本质上只是编程语言不够强大时的丑陋补丁，尤其是对 Java 语言来说。
文章配图参见 https://mp.weixin.qq.com/s/5ZHTKz01g4FqxVsXt8Rz3w。
Java 是设计模式的代言人
要说设计模式的“重灾区”，非 Java 莫属。
Java 是“设计模式狂热症”的代言人。几乎每个 Java 项目看起来都像是一个模子刻出来的，Factory、Singleton、Observer、Strategy …… 恨不得把所有 23 种模式都塞进去。
为什么 Java 成了这样？因为 Java 本身太啰嗦、太死板、太缺乏表达力。
就像写小说，但规定你只能用三音节以上的词——每个问题都被放大十倍。写个简单的 CRUD 应用？先来个 Factory，再加个 Observer 监听数据库变化，别忘了 Singleton，毕竟全局日志器总得有一个吧？
但这真的是“最佳实践”吗？还是这只是 Java 语言缺陷的遮羞布？
模式是语言的补丁，不是设计的智慧
设计模式不是在解决代码的问题，而是在解决编程语言的问题。
言外之意，就是设计模式在解决 Java 这门编程语言本身的问题。
以 Singleton 为例
看看 Java 里写一个单例要多少代码。
public class Logger {
private static Logger instance;
private Logger() {}
public static Logger getInstance() {
if (instance == null) {
instance = new Logger();
}
return instance;
}
}15 行代码，就为了表达我只想要一个实例。当然，最新的 Java 26 LazyConstants 另说，但它其实也不够简洁。
上面这是在写代码还是在考古？现代语言本该提供原生支持，但 Java 没有，对 Java 没有（Java 26 以后除外）。于是你不得不手写线程安全、延迟初始化这些本该语言层面处理的东西。
看看 Scala 是怎么做的。
object Logger就一行。Singleton 模式完成。没有对比就没有伤害，对吧。
没有静态块，没有线程安全，没有延迟初始化的废话。Scala 做了 Java 本该做的事，把单例当作基本语言特性，而不是需要手动实现的“模式”。
Factory 模式也是语言的锅
Java 的 Factory 模式，本质上是因为 Java 拒绝给你好用的构造函数或原生对象创建机制。在 Python、Ruby、Scala 里，很少需要 Factory。传个函数、用__init__灵活处理，问题就解决了。
函数是一等公民
Observer 模式？也一样，有函数一等公民就行了。
在支持一等函数的语言里，Observer 模式直接消失，把函数当参数传过去就完事了。
事实就是在表达力足够强的语言里，设计模式要么变得极其简单，要么根本不存在。语言可以直接解决问题，而不是套用一个 20 年前为老旧语言发明的抽象壳子。
过度工程化
设计模式还助长了一个更深层的问题过度工程化（Overengineering）。这是设计模式催生的一个大坑。
见过太多初级工程师（甚至一些资深工程师），一听到“设计模式”就两眼放光，拼命往项目里塞模式。他们在解决想象中的问题。
结果是什么？代码从“能看懂”变成“看不懂”，接口、工厂方法、奇怪的命名约定，像迷宫一样。读代码像在破译甲骨文。
记住一条铁律，如果你的解决方案需要画 UML 图才能解释清楚，那你已经走太远了。
好的设计模式往往被过度工程化，因为它们要适配尽可能多的场景。但过度工程化是有代价的，你得读它、理解它、理解它在整个系统里的上下文。任何技术都要评估收益是否大于成本。
大多数问题不需要设计模式。最简单的方案，往往就是对的。
设计模式唯一有价值的地方
说了这么多坏话，设计模式真的一无是处吗？
也不是，有一个诚实的价值，给复杂概念一个简短的名字。
在团队里，说“这里用了 Facade”比每次都解释“我们为什么要用三个类包一层”要高效得多。
仅此而已。
设计模式不是用来教你写代码的，而是用来讨论已经写好的代码的。它是标签，不是指南。理解底层原则，关注点分离、封装、组合优于继承——的开发者，哪怕从没听过 Singleton，也能写出干净的代码。
在老外大厂待过的很多程序员都反馈说，日常开发里没人天天念叨这些术语，面试也从没被问过（要是被问，有些人反而会觉得这是个 red flag）。
Gosling 哲学 vs Guido 哲学
DHH（Ruby on Rails作者）有个很妙的对比。
James Gosling（Java 之父）对程序员持悲观态度。他认为普通开发者给你太多权力就会自伤，所以 Java 被设计成“沙盒”，严格、安全、不让你乱来。这对要写 20 年代码的保险公司系统是好事，但对表达力是灾难。- Guido van Rossum（Python 之父）走了完全相反的路。他认为代码读得比写得多，所以要优化可读性，给程序员真正的工具。一等函数、装饰器、上下文管理器、鸭子类型，Python 让你直接解决问题，而不是绕一大圈走类继承和接口仪式。
- 设计模式是 Gosling 世界的产物。它们存在是因为语言不信任你直接解决问题。
在 Guido 世界的语言里，你直接 …… 解决问题。
写在最后
设计模式是语言不够表达力时的遗物。GoF 的 23 种模式里，有一半在 Python、Ruby、Scala 里直接消失，这本身就说明了一切。
它们从来不是关于“设计”，而是关于“语言别挡我的路”。
如果语言足够好，这个问题还存在吗？
以上，参考并翻译自 https://luminousmen.com/post/design-patterns-suck/。
最后，欢迎关注我的个人微信公众号：业余草（yyucao）！可加作者微信号：xttblog2。备注：“1”，添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系！
本文原文出处：业余草： » Java 成了设计模式的重灾区！