如何学习设计模式

言多必有失
在此做事，在外作人

虽然我上次和Dlee在那个贴子里面聊的时候说起过设计模式是基本知识，但从另一方面讲，设计模式的重要性其实怎么说都是不为过的。
首先，早期设计模式提出的时候是为了消除软件出版界和研究界的一些偏差：以前一些文章和研究都只是注重新技术，所谓的创新性。但其实在软件行业，新的技术层出不群，但很多基本的问题、很多现有技术足够可以解决的项目却没有很好的完成，设计模式的提出者包括Kent Beck,GOF和JimCoplien认为这是因为好的经验没有被足够的传播。所以在当时设计模式有点反叛主潮流的意思，但是这种反却反出了大名堂。《设计模式》被推崇为软件行业有是以来最重要的著作之一,我想最重要的原因就是认识到旧技术的良好运用在绝大多数时候比新技术更重要。设计模式的提出不但声明了这种经验的重要性，而且把它推上了大雅之堂。查一查IEEE论文，现在大学里面研究设计模式的人大有其在。
第二个重要贡献当然是软件设计行话的标准化。之前的很多行话或过于细节、或过于粗略，完全达不到精确表达和有效应用的程度。但设计模式把这些场景和解决方案固定化、细致化，这是非常重要的。我喜欢把设计模式看作李商隐的诗歌，虽然不能突破李白、杜甫的创新，但是却是整个有唐以来诗歌技巧的总结，是凝练了前人经验之上的升华。另一方面，这些概念的标准化把解决问题的起点从对象和方法提高到参与者结构关系和相互作用，毫无疑问可以把所有开发、设计、分析的水平提高到另外一个层次，我想每个人在初学设计模式的时候都会有这个体会。（立体几何的课后习题都有点小定理的意思，我记得以前学立体几何问题的时候，总是把课本后面的习题前提和结论都记牢，每次解题的时候我很少从正文的基本公式和定理开始推导、计算，而是针对问题的总前提，套用组合几个习题的答案。这样不但快的多，而且有时候不这样做比较难的竞赛体根本就解不出来）。
另外我认为这些基本模式务必精通，其中意图是最最重要的，解决方案则应该掌握好权衡，熟悉应用每一个模式的结果。在此基础上，设计模式就可以大大提高软件人员之间交流的信息量，很多复杂的问题可以通过简单的词汇进行讨论，因为大家都知道这一个简单的单词意味着什么、其中的细节是如何的、这样解决以后问题又会变成什么样子（好像有点心有灵犀一点通的意思）。我感觉，信息交流的频度和容量也是长久以来美国人软件超过中国人（或其他国家）的终极因素。
现在设计模式的作用则进一步体现在对编程方法和编程范式引导的作用。由于设计模式基本上展现了利用OO问题解决的最佳方案，所以它必然最充分地暴露出OO的缺陷。我仔细阅读过Visitor模式的论文大约有100多篇，很多人用反射、Meta、Closure、函数型编程等等试图解决Visitor模式的一些缺陷，都非常有见地。每一种新的编程范式，如AOP或旧的编程范式如functional,Smalltalk来演示自己的威力时都不约而同选择了设计模式绝不是偶然的。设计模式的典型性和示范作用无疑为新的语言和编程思想的发展奠定了良好的基础。

kent这个人据说人格魅力相当厉害，脑子也聪明（嘿嘿，我喜欢看他们的照片，比我秃的厉害，和他们比较起来我是个多发者）。
而实践模式据说也是他首先学习了《建筑永恒之道》而提出的。这个人就喜欢玩新瓶装旧酒的把戏，搞个XP也是把一些老掉牙的东西从新组合了一下。
有人说工程师是最保守的一群，因为他们只相信那些已经多次证明是有效的东西。
设计模式从根本上说只是一种发现而不是发明，这和后来XP中提出的让设计从代码中逐渐浮现出来是一个路子。
但是有效规有效，还是有没有覆盖和效果刚好相反的地方。而这些地方往往又是显示面向对象设计水平的地方。所以对于设计模式掌握的过程，是一个由不懂到懂，由懂到用，由用到喜欢用，由喜欢用到害怕用的过程。
但是我不认为什么人可以一下子达到最高峰，所以还是一步一步的来比较好。

在这里，我是新人，对大家也不熟悉。
只对robbin, bruce, sun2bin这3个人比较熟悉，因为喜欢看他们的文章。

我觉得要学好oo，必须先学好gof确实是屁话，如果一个人的oo经验足够，自己在任何场合都可以找到最适合的解决方案，是没有必要去花大量的时间来研究gof的那23种模式的，同意robbin的观点


是这样的，不过对于一个没有多少oo经验的设计师来说，研究一下gof的设计模式，可以更好的理解oo，减少自己的摸索时间

我认为设计模式是给初学OO设计者的一个理念，就是代码需要有很好的可扩展性和可重用性。理念也就是一种理论，在实践中起指导作用的，但决不是用来生搬硬套的。初学者有了这种理念就会在实践中慢慢领会最实用的各种招数，甚至发展出新的套路来。所以，在学习JAVA一段时间后，应该看一下设计模式方面的书籍。

说的不错，设计模式这种东西，在国内好象也就是这两年才兴起的。原来，没有听说过（我孤陋寡闻了 ）。不过，在接触过一段时间后，个人觉得还是有必要深入研究一下的，这样一方面对自己是一种提高，也可以，设计出更加健壮的代码。当然，我说的是有相当经验的程序员。对于初学者，我觉得还是不看为好，原因很简单，连接口和抽象类还没搞清楚是怎么会事，就去看这些东西，只会越看越迷。
这种东西，是一把双刃剑，用的好，可以提高程序的维护性、可扩充性等，用的不好，只会添乱。好与不好，仅在一线之间，没有相当的经验，是很难把握的。
至于，是不是要花很多的时间去学习、理解，这就仁者见仁，智者见智了，没有必要在这个问题上争来争取的。

Pattern 这种东西，要学习很容易.把书仍了,写代码去。代码看上去爽吗？不爽从新写写到爽为止。那就是模式了。
另外小声说一下:"代码复用，扩展之类也都是屁话不要相信说这种话的人，唯一有用的就是你的代码比较好看".

很对！



偏激了！不是这样的，写的代码比较多了，可以自己抽象出来很多可复用的类。有意识的运用一些模式，注重对代码的重构，对程序的可扩展性有很实在的好处，这些都是我自己的写代码做过的。

其实不就还是金庸小说笑傲江湖里面的道理，一个不懂武术的人，和独孤九剑都是无招，可是，中间有招的过程又如何能省？设计模式就是招，精通设计模式，到了通神境界，就是无招。可是中间的过程啊，能够有更加玄妙的招数，还是要学啊。至少比不会武功好啊。