关于模式的学习和使用交流（设计模式、架构模式。。）

如果你是非常有经验的朋友，如果你很少或没有设计和编码效率低的问题，请略过本文。

开门见山：

一、初学者如果第一次听说模式，可以拥有一本GoF的《设计模式--可复用面向对象软件的基础》，不学，放在手边当字典。

二、模式的学习，以实际问题为出发点，初学者熟悉最常见的两三种模式，对模式有直观认识即可。有经验的建议你用什么模式的时候，去查“字典”即可。

三、有一定积累之后，想学习了，如果GoF的看不深刻，又想系统学习，建议看《Head First设计模式》。

四、对于架构模式之类的，可以在工作中有系统设计开发的经验或者相关的基础以后，系统的“总结”学习，避免以偏概全。此时推荐几本书《敏捷软件开发——原则、模式与实践》，《企业应用架构模式》，《J2EE核心模式》（JEE领域的话），《面向模式的系统体系结构》（共5卷，建议选择性）。

如果你有兴趣，或者对上不认同，不妨往下读读，交流一下吧。

本文有点挑刺的感觉，所以想了很久才敢写下来，希望抛砖引玉。我喜欢通俗的阐述问题，所以，对于“是”这样的判断句，请谅解，我没有定义或装权威谈标准的意思，我是想对于特定的观点，以简单易懂的方式来说明。

设计模式、系统架构模式、企业应用架构模式、J2EE核心模式……，我们有很多专家、前辈和敬业研究者总结了很多的经验供大家学习交流，同时我们也许也总结了自己的经验，分享与他人。然而，很多人言必模式，设计的时候照着模式硬搬死套，coding的时候拿书对照。。。，有时候不得不佩服，毕竟他很专注，很认真，可从实际的角度，总让人觉得有点悲哀，怎么都有点以前抄八股文的感觉。

其实对于团队或者听来的其他公司的这些现象，我早想和这些朋友一起探讨下。

模式很好。因为它为一定环境下的场景提供了经过验证的成功的方案，运用模式，可以让我们少走弯路，提高效率。而且，模式也是大家解决问题时候进行交流、达成共识的共享知识库。

可是我为什么说那些抱着书本说模式的方法不好呢，原因很简单：没有了解模式来源以及相比其他方式的优势，是很难深刻理解模式的。所以我们经常看到模式的滥用、误用。

当然这样也许偏颇了，也许你就是例外，你有了一定经验，能够慢慢/或者很快就理解模式的深层次的东西，那你值得佩服。但是，我所知的一些朋友，如果没有经验的，对模式的了解大多是形式上的东西，导致使用起来，生搬硬套，效率地下，或者根本牛头马嘴，让人啼笑皆非，当然，我没有嘲笑的意思，我希望他们能理解我们的好心。

当然，对模式的推崇，尤其是对设计模式的过分推崇，导致很多人盲目的背诵、记忆，像背英文单词一样。这也许是行业的悲哀吧。

不才这里想和这些朋友讨论一下关于模式学习和使用的问题。当然我先抛砖，期待引来你玉了。

一、没有写过多少代码，也没进行太多详细设计的人，上来就系统的设计模式学习的方式，比如直接把GoF的《设计模式》拿来背诵的，勿取。本来设计模式是经验总结，几乎没有基础经验的，对不良设计没有概念，动辄用模式，常常将模式用成了不良设计。这种情况太多了，所以这里列出来。一方面，建议积累一点经验，或者从设计/编码结果上学习，一定积累后，再系统学习设计模式，效果也许要好得多。

现在流行的敏捷方法，其实对于模式的要求更高，而且，敏捷的很多方法对学习设计模式确是有益的，比如尽快建立可用的系统，然后需要的时候再进行重构，实际上对于有些朋友来说，就是不要求你写最好的代码，你就先写出来，觉得以前的代码不能解决问题了，就重构，这时候经过检验的优秀的模式也许就派上用场了。这样一个过程，定要比背八股文有意义的多吧。

对于这一点：推荐一本书：Robert.C.Martin的《敏捷软件开发——原则、模式与实践》，不是关于敏捷的方法、指导，而是设计的原则、模式，很好的一本书。

二、学模式，先学面向对象方法。设计模式的基础其实就是面向对象设计的原则，模式是在原则的基础上，对实际使用场景的归纳总结（不是定义和权威，是一种理解，请容许不准确）。面向对象的设计原则如SRP单一权限准则，OCP开闭准则等，网上搜搜吧，其实是很好的思想。

三、关于架构模式，建议有较多经验的朋友再去学习吧。推荐Martin Flower的《企业应用架构模式》。另外有一系列：《面向模式的软件架构》也许可以一睹。

四、具体领域：Java EE。我以前读《J2EE核心模式》的时候，感觉不深，后来SSH（Struts+Spring+Hibernat）用过之后，再回去，看该书的内容就经常拍案叫绝。还是建议有点实际经验，再系统学习吧（如果你已经知道这种方法不适合，请用自己的方法）。