@
sanbenweiyang #9
我随便搜个帖子给你：
https://www.infoq.cn/article/design-patterns-proposed-by-gof-20-years-ago摘抄一段：
```text
Gang of Four （简称 GOF ）似乎从一开始就将模式视为一种艺术 / 科学；在论著的最后一章（遗憾的是，读者们大多直接将其忽略），他们指出：
这本书的实际价值也许还值得商榷。毕竟它并没有提出任何前所未有的算法或者编程技术。它也没能给出任何严格的系统设计方法或者新的设计开发理论——它只是对现有设计成果的一种审视。大家当然可以将其视为一套不错的教程，但它显然无法为经验丰富的面向对象设计人员带来多少帮助。
但需要强调的是，实际情况在于：这本书中的模式设计理念尚未彻底完成。我在 DevelopMentor 上结识的一位朋友将设计模式称为“23 种指针使用方法”。好吧，似乎也有道理。
同样的，当管理层 / 高管团队将这本书甩给新手开发者并希望他们通过阅读实现技能“升级”时，结果也肯定会让他们深感失望。
```
你可以回头再看一下你举例的 linux 内核设计模式的站点：首先，这不是 linux 官方文档，而是其他人的总结；其次，这是针对 linux 内核而总结出来的，并不是 linux 内核根据 GOF 的设计模式进行的实践。
说道这里我不知道你有没有意识到自己对设计模式的理解存在的问题，如果没有，我进一步直接告诉你：你把设计模式与代码架构的先有鸡还是先有蛋的顺序搞反了（例如我上面解释了你对 linux 内核那个设计模式套过来做论据的错误）。
设计模式并不是只有 GOF 整理的这些，GOF 整理的这些也并不适合直接用于代码设计。设计模式的运用的最佳实践，应该是先有业务和代码，在实现以及发展的过程中，甚至是在日后重构的过程中，结合这个项目整理出项目本身对应的设计模式（实际上不只是整理设计模式，还应该整理项目的各种定义、规范等）。用既定的设计模式去设计架构、大型代码模块，只有一个大场景和很多小场景符合，大场景比如已经成熟的行业领域，比如传统企业级，已经多年深耕、架构、代码、模式成熟，所以当你从头再造一套，那些在这个领域已有的设计模式能帮助提高生产效率。小场景也是类似的道理，已有成熟的体系才行。而直接拿设计模式不分青红皂白往各种项目上套，八成制造更多屎山。
至于设计模式跟语言无关，那你可是更没理解到位了。比如单例，对于有全局变量或者全局静态变量的语言比如 c/cpp/go ，最简单的就是一个全局变量就搞定了，再多封装单例模式的 N 种写法也都是脱裤子放屁或者仅仅看上去接口 /方法的形式或许比变量更优雅而已（然而这种审美也是因人而异）。
总结起来，就是现有的代码实践，然后才有对应的整理出来的设计模式，如果使用这些模式去指导类似的业务或者逻辑的代码架构是存在一定合理性的，但生搬硬套是扯淡，尤其在这些年 IT 互联网行业高速发展、需求快速迭代的场景。这一点上，OOP 存在类似的问题，比如鸭嘴兽，比如快速迭代无法预测未来需求的快速变化，你在早起想在顶层设计阶段使用设计模式、OOP 做到日后的易扩展，简直就是痴人说梦。只有阶段性重构能真正让屎山改造成艺术品