robbin 等级:
更多相关推荐 随便谈谈我对设计模式的看法吧。我极度反感言必称设计模式，什么要学好OO，必先学好Gof这类的屁话。
坦率说我也从来不刻意的去学习设计模式，我看到身边的朋友花那么多钱去买一大本厚厚的阎博士的设计模式的书，心里总是叹息一下，设计模式不是学出来的，是用出来的。
设计模式应该怎么学习？应该我花两个小时给你讲一下，告诉你每个模式是怎么回事，应该在什么场合适用就OK了，这样就学完了。
然后你在自己的工作实践中，碰到了这类问题，想起来自己曾经听xx说过可以使用xx模式，于是乎，你再把阎博士的书打开看看(或者把banq的文章翻出来看看)，进行 copy & paste。这样就够了，充分够了。
你真的完全没有必要把模式看的多么神圣，多么神秘，多么高深，它就是一个让你去copy & paste的代码片断，如此而已。
所以Gof的书那么薄，因为作者知道设计模式本来就不是一个可以学出来的东西，所以Sun的J2EE模式就算加上了冗长的代码和罗嗦的描述，也是薄薄一本。
把一本模式的书写的如此之厚，我认为已经失去了学习它的价值了。
而且“设计模式”这个词汇广义的来说指的是适用于特定场合的经过验证是良好的解决方案。
其实只要你有足够的工作经验，就算你没有学过设计模式，你写出来的代码也会不知不觉符合某种模式的要求的。因为你经过很多实践经验，你已经积累了很多，你知道在什么场合代码应该怎么写，那么“在什么场合代码应该怎么写”这本身就是设计模式。
所以我认为没有必要刻意去学习设计模式，也没有必要把设计模式当做多么神圣的东西。
只要你的OO编程经验达到了一定的水平，设计模式本来就是无师自通的。如果你的编程经验很少，你就是把Gof背得滚瓜烂熟，到时候你一样用不出来。
设计模式就像围棋中的定式，如果你是高手，你下的棋自然而然的符合一些定式的走法，如果你是初哥，你就是背了几千个定式，只要对手不按照定式来走，你就一点都用不上。
再说Gof的23种模式只不过是设计模式的沧海一粟，Sun的J2EE有15种设计模式，你还要不要学，要不要背？ 不说别的，Hibernate现在也出了20种设计模式了，那是不是说你不把Hibernate的20种设计模式背的滚瓜烂熟，你就不可能把Hibernate学好用好呢？
总结一下我的观点：
设计模式就是定式，碰到这种场合你才用得上，所以学习设计模式，你只需要花2个小时过一遍，脑子里面有个印象就赶快收手，到用的时候再去copy & paste。这样就够了。如果你告诉你花了几个月去钻研设计模式，我只能告诉你，你在浪费青春。
总之，水平没到，学也白学，水平到了，无师自通。所以不要学设计模式，看一遍就用，用多了，你自己也可以总结设计模式了。
dlee 等级:
我比较赞同 robbin 的看法，虽然我学习设计模式花费了不少时间（一两个月吧）。设计模式应该象手边的工具箱一样，我需要一把尺子就拿一把尺子来用，需要一只圆规就拿一只圆规来用，没有必要神秘化。
在有些场合，如果不可能发生大的变化，就不要用设计模式，而用更简单的代码来实现。拥抱变化并不意味着过度设计。
其实我们在开发中一些常用的注意事项和解决问题的通用套路就是设计模式。
《设计模式》这本书确实不太适合初学者，因为书的作者主要注重的是准确性而不是可读性。这也是这本薄薄的小书我看了一个月之久的原因。也是为什么会有那么多解释这本书的书出现的原因。
但是我的趣味是直接阅读大师的原著，那些让我感到痛苦的书往往收获是最大的。我第一遍读这本书的时候相当于是郭靖背九阴真经，现在一年半时间过去了，总算有了一些比较深入的理解。
ozzzzzz 等级:
嘿嘿。我觉得看看阎博士的书还是对初学者还是很有帮助的，至少他们可以从那本书中明白正方形不是长方形的子类。但是要是依赖那本书进入设计模式的大门是不可能的，就是GoF的书我也不认为能让谁入门。
在我看来设计模式也好，RUP也好，XP/AGILE也好都是工具，都有约束。知道什么时候用设计模式不重要，重要的是知道什么时候不要用设计模式。就这一点阎博士承认他的书没有对这个问题作深入的探讨。
你用定式来说明设计模式很好，而学习定式的最佳途径就是实际使用定式。所以你说“设计模式不是学出来的，是用出来的”。
GoF自己说他们并没有发明设计模式，而只是发现了设计模式。这就告诉我们可以通过积累发现新的模式。但是作为初学者还到不了无师自通的地步。要想提高水平，还必须学习一些前人的经验，而看看那些别人写的书还是对他们很有帮助的。
不要自己发明轮子，是不是？学习一些套路还是对于提高水平有帮助。
学习也不能盲目，没有什么东西是打遍天下无敌手的。
孤魂一笑 等级:
实用点吧，设计模式的根本也是为了代码重用，那只要你做到了很好的代码重用，你是否是否了GOF 设计模式23 种之一根本不重要，首先是目标明确，再寻找有效的手段，而不是先我知道一种很好的方法，我要把他运用到那里去。
至于他们两个人，我们也没有必要去评价。毕竟我们很多事情不清楚。
ozzzzzz 等级:
在我看来GoF当然是为了重用，但是不仅仅是重用，特别是代码的重用。可以说没有GoF就没有architecture和framework，设计模式可以说是现在设计的核心基础，它给了我们一个认识问题解决问题的途径。但是不能就此认为设计模式是什么玄奥无比难于掌握的东西。
设计的本质在于权衡，而GoF只给我们提供了一个解决问题的方法，具体使用这种方法会有什么后果还要我们自己去掌握。
我认为设计模式的根本其实在设计模式之外。
dlee 等级:
我觉得理解了设计模式，再发现新的模式相对来说是比较容易的事情。但是如果完全不理解设计模式，自己也不容易发现新的模式，提高代码的重用性也是空谈。也许你自以为重用性已经最高了，但是别人用设计模式帮你重构一下后你发现居然还有那么多重用性可以提高。
如果你象我的一个朋友一样写过几十万行代码，独立设计过多个开发框架。那么设计模式对你来说确实不是非常重要。但是普通程序员并没有那么多机会开发大项目，所以深入学习设计模式还是很有必要的。
这个问题没必要争论，不是要不要设计模式的问题，而是如何用好的问题。
robbin 等级:
引用
设计模式的根本也是为了代码重用，那只要你做到了很好的代码重用，你是否是否了GOF 设计模式23 种之一根本不重要，首先是目标明确，再寻找有效的手段，而不是先我知道一种很好的方法，我要把他运用到那里去。
我觉得这句话真的说到我想表达的意思上了。只要你的代码结构良好，至于到底有没有所谓的设计模式，根本就是不重要的了。打个不恰当的比喻，一个好的杀手，他的目标就是一剑封喉，干脆利索的杀了目标，你管他杀人用的那一招究竟是华山派的什么剑法，还是嵩山派的什么剑法。达到目标就行了。而且你的剑法练到一定的程度，你可以自创剑法，这个世界绝没有你练熟了世界上的剑法，你就是绝顶高手的道理。至于你已经达到了高手的境界以后，一招一式无不合剑道之极致。也就根本无所谓用什么招式了。
ozzzzzz 等级: 资深会员
不过我不怎么同意你们关于GoF根本是为了重用代码的说法，这样说太看重代码重用的了。设计模式还是一种解决方案的总结而不是具有实施的总结，它的所处的层次应该是在代码层上，在framework层下。
“你是否是否了GOF 设计模式23 种之一根本不重要，首先是目标明确”这句话绝对正确，但是问题在于目标明确是非常困难的事情。为什么说设计的本质是权衡，就在于你很难只确定一个目标，更难确定一个固定的目标。你要考虑的往往是在多种约束下的多种可能解决方案。我不认为有哪种解决方案是唯一正确的，这就是设计策略和风格的问题。作为初学者肯定会经过一个痴迷于设计模式并且看到所有的东西都是钉子的阶段，这不可怕。要是他们不经过这个阶段，也不会到达无招的阶段。
而在初学者成熟前，我认为让他们先掌握几种解决方案，然后去努力的在现实中寻找使用这些方案的合适场景是不错的选择。
所以不管他们两个中的哪一个都是为初学者作了很多有意贡献的人，是值得初学者学习的。
而我想初学者不能因为他们之间有矛盾，就信奉一个排斥一个。
potian 等级:
虽然我上次和Dlee在那个贴子里面聊的时候说起过设计模式是基本知识，但从另一方面讲，设计模式的重要性其实怎么说都是不为过的。
首先，早期设计模式提出的时候是为了消除软件出版界和研究界的一些偏差：以前一些文章和研究都只是注重新技术，所谓的创新性。但其实在软件行业，新的技术层出不群，但很多基本的问题、很多现有技术足够可以解决的项目却没有很好的完成，设计模式的提出者包括Kent Beck,GOF和JimCoplien认为这是因为好的经验没有被足够的传播。所以在当时设计模式有点反叛主潮流的意思，但是这种反却反出了大名堂。《设计模式》被推崇为软件行业有是以来最重要的著作之一,我想最重要的原因就是认识到旧技术的良好运用在绝大多数时候比新技术更重要。设计模式的提出不但声明了这种经验的重要性，而且把它推上了大雅之堂。查一查IEEE论文，现在大学里面研究设计模式的人大有其在。
第二个重要贡献当然是软件设计行话的标准化。之前的很多行话或过于细节、或过于粗略，完全达不到精确表达和有效应用的程度。但设计模式把这些场景和解决方案固定化、细致化，这是非常重要的。我喜欢把设计模式看作李商隐的诗歌，虽然不能突破李白、杜甫的创新，但是却是整个有唐以来诗歌技巧的总结，是凝练了前人经验之上的升华。
另一方面，这些概念的标准化把解决问题的起点从对象和方法提高到参与者结构关系和相互作用，毫无疑问可以把所有开发、设计、分析的水平提高到另外一个层次，我想每个人在初学设计模式的时候都会有这个体会。
另外我认为这些基本模式务必精通，其中意图是最最重要的，解决方案则应该掌握好权衡，熟悉应用每一个模式的结果。在此基础上，设计模式就可以大大提高软件人员之间交流的信息量，很多复杂的问题可以通过简单的词汇进行讨论，因为大家都知道这一个简单的单词意味着什么、其中的细节是如何的、这样解决以后问题又会变成什么样子（好像有点心有灵犀一点通的意思）。我感觉，信息交流的频度和容量也是长久以来美国人软件超过中国人（或其他国家）的终极因素。
现在设计模式的作用则进一步体现在对编程方法和编程范式引导的作用。由于设计模式基本上展现了利用OO问题解决的最佳方案，所以它必然最充分地暴露出OO的缺陷。我仔细阅读过Visitor模式的论文大约有100多篇，很多人用反射、Meta、Closure、函数型编程等等试图解决Visitor模式的一些缺陷，都非常有见地。每一种新的编程范式，如AOP或旧的编程范式如functional,Smalltalk来演示自己的威力时都不约而同选择了设计模式绝不是偶然的。设计模式的典型性和示范作用无疑为新的语言和编程思想的发展奠定了良好的基础。
ozzzzzz 等级: 资深会员
kent这个人据说人格魅力相当厉害，脑子也聪明.
而实践模式据说也是他首先学习了《建筑永恒之道》而提出的。这个人就喜欢玩新瓶装旧酒的把戏，搞个XP也是把一些老掉牙的东西从新组合了一下。
有人说工程师是最保守的一群，因为他们只相信那些已经多次证明是有效的东西。
设计模式从根本上说只是一种发现而不是发明，这和后来XP中提出的让设计从代码中逐渐浮现出来是一个路子。
但是有效规有效，还是有没有覆盖和效果刚好相反的地方。而这些地方往往又是显示面向对象设计水平的地方。所以对于设计模式掌握的过程，是一个由不懂到懂，由懂到用，由用到喜欢用，由喜欢用到害怕用的过程。
但是我不认为什么人可以一下子达到最高峰，所以还是一步一步的来比较好。
robbin 写道
而且“设计模式”这个词汇广义的来说指的是适用于特定场合的经过验证是良好的解决方案。其实只要你有足够的工作经验，就算你没有学过设计模式，你写出来的代码也会不知不觉符合某种模式的要求的。因为你经过很多实践经验，你已经积累了很多，你知道在什么场合代码应该怎么写，那么“在什么场合代码应该怎么写”这本身就是设计模式。
robbin 写道
水平没到，学也白学，水平到了，无师自通。所以不要学设计模式，看一遍就用，用多了，你自己也可以总结设计模式了。
Trustno1 等级:
Pattern 这种东西，要学习很容易.把书仍了,写代码去。代码看上去爽吗？不爽从新写, 写到爽为止。那就是模式了。
另外小声说一下:"代码复用，扩展之类也都是屁话, 不要相信说这种话的人，唯一有用的就是你的代码比较好看".
robbin 等级:
偏激了！不是这样的，写的代码比较多了，可以自己抽象出来很多可复用的类。有意识的运用一些模式，注重对代码的重构，对程序的可扩展性有很实在的好处，这些都是我自己的写代码做过的。