为什么要学习别人的设计模式？ 第1页

你的感觉是对的，事实上设计模式最主要的作用就是装逼。

再强调几次：

设计模式的名称不是业界共识，而且很多名字一点儿都不形象，纯属凑，有些模式被语法取代，有些模式其实蛋疼。和菜谱根本不是一回事儿。

设计模式是基础的OOP套路，既不高深，也不绝对正确，存在了数年才被提炼总结，设计模式就是本普通的入门书籍，价值在于通俗易懂，快速上手，利用一些简单的原则提高代码可复用度。

了解一下以资参考便可，死记硬背，奉为圭臬是装逼过头。

事实上个人甚至觉得原版的《设计模式》就是一本烂书。

因为设计模式的精妙之处必须在特定的场景才能体现，而书中的场景其实很多构造的非常生硬，难以引起共鸣，一些名称并不贴切，还有一些模式其实是很多技巧的组合，一些模式又是一些大的技巧中的一个小环节，提炼出来的23种所谓模式在当时的Java语言上按部就班的开发各种企业软件算是涵盖的比较全面。但是随着语言和技术的发展，许多模式早已过时，还有很多模式显得非常的不合时宜。

反之，软件工程领域的《人月神话》，其中论述的道理即使放到今天甚至十年后都不会过时，作者的段位根本不是一个档次的。

PS：看到反对本来挺高兴，结果一看完全言之无物。《设计模式》中的design pattern自有其价值，但目前显然过誉，而且design pattern多如牛毛，这种所谓经典反而不见得可以开拓思路。提问者自己有所感悟，略有所得，的确无需生搬硬套，正如提问者所说，参考参考本是正道。他人装逼，提问者不爽，我秉笔直言，他人的确装逼，提问者感觉无误。

反对意见中其实错漏百出，例如MVC绝对谈不上design pattern，更不可能出现在所谓的23种design pattern中。MVC是高屋建瓴的模式，决定整个系统的整体架构和模块设计。是architectural pattern的一种，其本质之精髓又在于Model和View的解耦，透过Controller来巧妙协调，早期MVC模式和现在广泛运用于网站开发中的MVC结构神似，而产生的背景不同，解决的问题也有差别。

举例中的成就系统，使用observer pattern解耦，实则强行穿刺游戏系统以暴露事件。若遇需求变更需要监听尚未公开的事件，则会带来额外负担。而成就系统不可能一开始就设计完全，游戏系统只好将所有可能监听的事件逐一暴露以降低未来可能的修改，却又会陷入过度设计的泥沼。