如何学习设计模式

随便谈谈我对设计模式的看法吧。我极度反感言必称设计模式，什么要学好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。这样就够了。如果你告诉你花了几个月去钻研设计模式，我只能告诉你，你在浪费青春。

总之，水平没到，学也白学，水平到了，无师自通。所以不要学设计模式，看一遍就用，用多了，你自己也可以总结设计模式了。

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

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

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

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

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

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

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

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

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

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

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

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

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