在 2026 年如果有需要手搓代码的场景的话，其实不用很在乎设计模式了。

这个词其实灵感是源于工程学，根本就不是计算机领域的东西。它起源于 1994 年那本出版《设计模式》一书，里面鬼迷心窍搞了 23 种建筑学工程学里的模式来与代码一一对应，然后便是噩梦的开始了。。。

其实本身研究一下，类比一下，也不是坏事，但谁想到，这个竟然变成了教条一样！跟国内过去流行的四书五经的八股文一样，被大大的夸张化了（最开始 C++ ，后来 Java 的助推，不用就没法玩，让设计模式普及功不可没）。

本身就是当年灵机一动搞的概念，被神话了。被当成了万能解决方案。

完全没有必要！

遵守设计模式，我还能接受，但是太教条就过分了。

我们公司代码中的设计模式... 大部分都是前任练手的玩具代码，耍杂技的。

其实就是一种过度工程崇拜，类似于宫廷礼仪、文言文一样仪式感。

代码里用了 Factory，很专业，用了 Observer，更专业，再套几个 Interface，一下子两眼放光，架构感上来了，帅呆了上瘾了。

最可怕的是类的继承体系，几个类，深度耦合起来，然后各种继承出一大堆类，这玩意儿真是灾难，至今想起来都鸡皮疙瘩。

其实所谓的瓶颈问题都是虚构的，并不存在，我写了 6 年 JS TS 了，全是单刀直入，开门见山，从没遇到教科书里担心的问题。真的。反而代码变得越来越抽象和难阅读，甚至还得画 UML 图。

要相信后人的智慧，不要太给后人过度铺路，没意义。

Kirill Bobrov 说过：事实上，大多数问题都不需要。通常最简单、最直接的解决方案才是正确的。一个经验法则是：如果你的解决方案需要画图来解释，那就说明你做得过火了。

尤其是批评把设计模式刻进骨子里的 Java ！现在 AI 时代还好，过去你知道写 Java 多么难受吗？大大把简单问题复杂化，僵硬赘余的写法。

比如就写一个获取配置并展示，得搞个观察者、再加个单例、拌来拌去搞了一个工厂模式......

你看看这麻烦的单例模式，13 行啊我的天：

public class AppConfig {

    private static AppConfig configInstance; // 唯一的配置对象
    private AppConfig() {} // 私有构造方法，让外部无法直接创建对象

    // 获取全局配置实例
    public static AppConfig getConfig() {
        if (configInstance == null) { // 初始化
            configInstance = new AppConfig();
        }
        return configInstance; // 返回配置
    }
}

完全就是套模板，还被吹嘘为「最佳模式」！

直接封装一个类就行了，就像 JS 里，当成 Obj 直接 let 一个完事！

在 JS （TS）和 Python 里你有用过 设计模式 吗？谁用那玩意儿？！

在灵活的语言里，大部分 设计模式 基本消失的无影无踪。

海外的机器学习工程师 Kirill Bobrov 曾经举过 Python 不需要设计模式的例子：

在 Python 中：
需要工厂模式？只需巧妙传递一个函数或使用 __init__ 即可。
想要单例模式？用一个模块或初始化一次的类就能搞定，一天的工作量都不到。
观察者模式？函数可是一等公民，直接传递它们就行了。

这足以证明设计模式，其实就是一张纸等待被捅破（已经被捅破了），束缚思想。

设计模式也不是完全没用，确实发明了很多计算机领域的专业术语（行业内黑话），方便程序员间沟通，但也仅限于此。推崇者往往张口模式，闭口对象。睁眼谈领域逻辑，闭眼吹高性能架构。设计模式带来的问题往往比解决的问题更多....

设计模式吹的什么好处都有，唯独不包括可读性......

Java 和 Python 就是两种理念的产物，后者这种自由灵活，解放了思想。大家怎么看？喜欢前者还是后者？

参考资料：

https://www.informit.com/articles/article.aspx?p=1327762

https://www.informit.com/store/design-patterns-elements-of-reusable-object-oriented-9780201633610

https://luminousmen.com/post/design-patterns-suck/