我比较赞同 robbin   的看法，虽然我学习设计模式花费了不少时间（一两个月吧）。设计模式应该象手边的工具箱一样，我需要一把尺子就拿一把尺子来用，需要一只圆规就拿一只圆规来用，没有必要神秘化。在有些场合，如果不可能发生大的变化，就不要用设计模式，而用更简单的代码来实现。拥抱变化并不意味着过度设计。
               其实我们在开发中一些常用的注意事项和解决问题的通用套路就是设计模式。
               《设计模式》这本书确实不太适合初学者，因为书的作者主要注重的是准确性而不是可读性。这也是这本薄薄的小书我看了一个月之久的原因。也是为什么会有那么多解释这本书的书出现的原因。
               但是我的趣味是直接阅读大师的原著，那些让我感到痛苦的书往往收获是最大的。我第一遍读这本书的时候相当于是郭靖背九阴真经，现在一年半时间过去了，总算有了一些比较深入的理解。
               这个帖子讨论设计模式似乎是不太合适，呵呵。

ribbin
               嘿嘿。我觉得看看阎博士的书还是对初学者还是很有帮助的，至少他们可以从那本书中明白正方形不是长方形的子类。但是要是依赖那本书进入设计模式的大门是不可能的，就是GoF的书我也不认为能让谁入门。
               在我看来设计模式也好，RUP也好，XP/AGILE也好都是工具，都有约束。知道什么时候用设计模式不重要，重要的是知道什么时候不要用设计模式。就这一点阎博士承认他的书没有对这个问题作深入的探讨。
               你用定式来说明设计模式很好，而学习定式的最佳途径就是实际使用定式。所以你说“设计模式不是学出来的，是用出来的”。
               GoF自己说他们并没有发明设计模式，而只是发现了设计模式。这就告诉我们可以通过积累发现新的模式。但是作为初学者还到不了无师自通的地步。要想提高水平，还必须学习一些前人的经验，而看看那些别人写的书还是对他们很有帮助的。
               不要自己发明轮子，是不是？学习一些套路还是对于提高水平有帮助。
               学习也不能盲目，没有什么东西是打遍天下无敌手的。

ozzzzzz:
               你把robbin 的名字写错了，允许你say sorry.开玩笑了。

实用点吧，设计模式的根本也是为了代码重用，那只要你做到了很好的代码重用，你是否是否了GOF 设计模式23   种之一根本不重要，首先是目标明确，再寻找有效的手段，而不是先我知道一种很好的方法，我要把他运用到那里去。
                   至于他们两个人，我们也没有必要去评价。毕竟我们很多事情不清楚。

robbin
               sorry。把你的名字和我另外一个朋友的名字搞混了。该死该死。
               孤魂一笑
               在我看来GoF当然是为了重用，但是不仅仅是重用，特别是代码的重用。可以说没有GoF就没有architecture和framework，设计模式可以说是现在设计的核心基础，它给了我们一个认识问题解决问题的途径。但是不能就此认为设计模式是什么玄奥无比难于掌握的东西。
               设计的本质在于权衡，而GoF只给我们提供了一个解决问题的方法，具体使用这种方法会有什么后果还要我们自己去掌握。
               我认为设计模式的根本其实在设计模式之外。

我觉得理解了设计模式，再发现新的模式相对来说是比较容易的事情。但是如果完全不理解设计模式，自己也不容易发现新的模式，提高代码的重用性也是空谈。也许你自以为重用性已经最高了，但是别人用设计模式帮你重构一下后你发现居然还有那么多重用性可以提高。
               如果你象我的一个朋友一样写过几十万行代码，独立设计过多个开发框架。那么设计模式对你来说确实不是非常重要。但是普通程序员并没有那么多机会开发大项目，所以深入学习设计模式还是很有必要的。
               这个问题没必要争论，不是要不要设计模式的问题，而是如何用好的问题。

阎宏确实有把简单问题复杂化的tend，既使是入门，也是以简洁为胜，他这样子狂举传说故事
               与我欣赏的自明性原则不兼容。

BANG如果用了他的图，那也是不太好，不过BANG后来删掉了。

设计模式肯定是要用的。
               不过我是先按照自己的开始构想去实现代码，这一步骤以达到目的为主，当然写代码的时候就会去考虑使用那些模式，在做重构的时候可能侧重符合设计模式就更多点。我是很怕有些人为了设计模式而设计模式反而先给自己下个套。
               很多是为了设计模式而设计模式那其实有点那个什么。

再说一下阎博士的那本书，其实他在讲述设计模式之前的那些OO原则的讲述很不错。

引用

设计模式的根本也是为了代码重用，那只要你做到了很好的代码重用，你是否是否了GOF 设计模式23   种之一根本不重要，首先是目标明确，再寻找有效的手段，而不是先我知道一种很好的方法，我要把他运用到那里去。

我觉得这句话真的说到我想表达的意思上了。只要你的代码结构良好，至于到底有没有所谓的设计模式，根本就是不重要的了。打个不恰当的比喻，一个好的杀手，他的目标就是一剑封喉，干脆利索的杀了目标，你管他杀人用的那一招究竟是华山派的什么剑法，还是嵩山派的什么剑法。达到目标就行了。而且你的剑法练到一定的程度，你可以自创剑法，这个世界绝没有你练熟了世界上的剑法，你就是绝顶高手的道理。至于你已经达到了高手的境界以后，一招一式无不合剑道之极致。，也就根本无所谓用什么招式了。

感觉自己在胡说八道，引人入歧途，不过这是灌水版，还好还好。

robbin
               嘿嘿这次写对了。
               就是吗？这个地方其实是谈问题的最好地方，反正错就错了。谁也不认识谁。
               不过我不怎么同意你们关于GoF根本是为了重用代码的说法，这样说太看重代码重用的了。设计模式还是一种解决方案的总结而不是具有实施的总结，它的所处的层次应该是在代码层上，在framework层下。
               “你是否是否了GOF 设计模式23   种之一根本不重要，首先是目标明确”这句话绝对正确，但是问题在于目标明确是非常困难的事情。为什么说设计的本质是权衡，就在于你很难只确定一个目标，更难确定一个固定的目标。你要考虑的往往是在多种约束下的多种可能解决方案。我不认为有哪种解决方案是唯一正确的，这就是设计策略和风格的问题。作为初学者肯定会经过一个痴迷于设计模式并且看到所有的东西都是钉子的阶段，这不可怕。要是他们不经过这个阶段，也不会到达无招的阶段。
               而在初学者成熟前，我认为让他们先掌握几种解决方案，然后去努力的在现实中寻找使用这些方案的合适场景是不错的选择。
               所以不管他们两个中的哪一个都是为初学者作了很多有意贡献的人，是值得初学者学习的。
               而我想初学者不能因为他们之间有矛盾，就信奉一个排斥一个。

设计模式我认为还是用出来的，就像Robbin说的那样，不需要去刻意的学习设计模式的多少种模式，只需要大体的了解一下每一种设计模式他之所以这样设计的好处，及大体的框架就ok了，那你每次进行设计或开发的过程中，或者在你遇到困惑的时候，就会不自觉地想到某种模式可以给自己带来方便和解决困惑，或者让别人能更好的看懂之类的好处。。。而且在开发和使用模式的过程中会慢慢的提高自己的这方面的水平。
             至于什么bang，阎博士，不关心。演博士没看过，bang的也是听别人说jdon采来的，对收费比较讨厌，难道就缺那点钱？就算缺，也不至于这样。

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

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