我的看法和各位有点不同。
首先从模式的来源看。模式的开端是亚历山大的模式语言（pattern language）,其根本目的是为了描述建筑的本质，也就是其所谓的“道”。“任何一个伟大的建筑都是由极近此道的人建造起来的。”设计模式也是借鉴这种观点，采用模式来描述软件设计中的本质的问题。找到了问题的本质，我们就不担心变化了，因为“万变不离其宗”。这也是为什么设计模式可以不断的重用的原因，抓住了本质。
模式是用来描述问题域的，是一个高抽象级别的思维。亚历山大使用模式语言来描述建筑与自然，与人、与社会等等的接口，软件也是一样。面向接口编程，使我们脱离了具体的实现，可以更深入的关注问题的本质，从而获得高复用级别的组件。
而使用模式，不是模式本身的的问题。使用模式是为了更好的理解系统，使用模式来描述系统，是为了可以在进行高级别的抽象。模式是用来思考的。许多人在开发的过程中，不断的在套用模式，背离了模式的初衷，而且效果也不好。正确的方向是理解目标系统，而且越深越好。
我觉得在开发中不应该太注重要运用某某模式,而是应该注重了解自己的业务
在设计中根据自己某种业务在决定运用某种模式,不能为了要用模式而用它
模式的目的就是为了简化我们开发者的工作量,增加复用性,可读性,等等
虽然会带来代码有一点冗与,但也带来了可移植性,模快化等等
所以要求系统的设计者根据自己的需要而设计,不能为了使用模式而在设计中决定采用某个模式,很多时候在开发过程中不知不觉的用到了很多模式,只是我们没有去回味而已,不信大家可以回想一下以前设计或开发过的系统看看!!!
一定收获不小!!!
jdk本身融入了很多模式，如果是数据库典型的就是工厂模式，例子是jdbc，连接池典型是单例模式。做界面（b/s和c/s）典型是观察者模式，象Iterator模式java提供了实现.........，模式提供的是场景，属于架构实现方面的东东，模式本身提供了清晰的架构，从而带来好的扩展性。模式应用的多少和范围应该有度，比如实在不可能大的项目，本身就不复杂，就不要乱用模式，在可能扩展的地方使用模式是有必要的。
有**特色的自己的模式,才好.
MODEL1,MODEL2是体系结构还是模式?有什么区别?
无需过分追求MODEL1,MODEL2是体系结构还是模式的区别，两种都可以称。
模式就是分层解决问题，一个问题分成几个问题层，其中要保证，这些问题是包含的，下层解决的问题上层可以利用，A》B》C。。。，我们就先解决c，解决b时可以构建在c的解决方案上，以此类推，最后全部解决，出了问题，各自负责，层层下推（有点象踢皮球）
wm_creat 理解深刻，这个其实类似是一个树形串，所以我将之抽象概括为：模式是解决调用者和被调用者之间耦合的关系，通过不同的模式，展现根据不同的应用要求而实现的调用者和被调用者之间的解耦目的。
mvc,有大的，有小的，也就是有高层次的有低层次的，存乎一心。我觉要在模式里面寻找灵感，别局于模式。关键是把他们用到自己所做的项目中，不能为了模式而模式，应模式驱动，多用自己掌握，或比较熟悉的模式，探索能不能把一些原来没用过的模式添加到自己的项目中来。
刚学java在看jive源码
看得很模糊.
看了楼上的各位的发言,深有感触
我只是一个大4学生，还没什么实际的开发经验，看到这里，也想说两句：
对于设计模式，XP这些东西。总是觉得有很矛盾的地方。
我一直觉得java简单就是美，假如用了太多的模式的话，代码总觉得不够直观，不简洁。连new个对象都绕来绕去的，烦躁！
但是有的时候不使用模式的话。系统的可重用性，可扩展性，构件之间的耦合程度又太差！
所以我觉得只要理解好OO编程的基本原则就行了，用不着刻意的去使用一些模式。其实所谓的模式也是这些基本原则的一个具体应用而已！
PS:我知道这里牛人很多，小菜鸟初出茅庐，理解不对的地方希望能有高人点拨一下！^^
> 对于初学者：先学习掌握GoF设计模式，再学习UML和Rose，千
> 虮鸬叩构矗脖鹨晕褂UML后，可以回避.NET和Java具体
> 胙≡瘢扛鱿低车纳杓品桨覆皇鞘褂UMl就可以完全表达清
> 摹?>
> 我也希望UML真的如它的名字统一天下语言，早点放弃难学的J
> va和设计模式。
这个话说得外行， 初学者， 当然应该先学 UML, 再学设计模式。
至于 UML 一统天下， 这种观点也是要命的不对。即使 UML 一统天下， 设计模式照样要学。 这两个东西是可以 互相替代的吗？
> 我最近也在研究模式。
> 我对模式的理解就是：
> 一句话可以用白话讲，很长
> 而如果这个含义可以用成语讲，岂不是更妙？
>
> 模式就和成语一样，只是不同领域有不同的用途。
>
>
>
> 适合用成语的时候，可以用，但是不适合的时候还是讲白话?> 。
>
> 所以我很注重模式的应用场景，以及模式的组成，这两者必?> 熟练了
> 才能用的很熟。
>
> 一个成语，如果不了解其含义，我想谁也不会用吧？
> 同样，对于模式，仅仅知道模式的名字是不行的
> 了解含义也就是 应用场景和模式的组成
> 是使用的前提。
>
非常精辟！
>SportsBaby1980 :
>模式和成语的对比。
理解是正确应用的前提。
>SwimLurker
>学习模式应该注重其解决问题的环境和方法
任何事物都有局限性。模式是“特定问题”的通用解决方案。针对性是必须考虑的问题之一。
还记得“没有银弹……”吗？
>Azure_2003
>1、某些模式解决某些问题是非常有效的
用模式思考有助于解决特定的问题。
前提是要理解哪种模式对于解决哪类问题更有效。
>2、不一定非得要使用比较纯的模式
综合应用 更接近最优解决方案(特定条件下的最优)。
>3、模式得精华在于扩展性和复用性，模式的扩展性和复用性思想是主要的，如何使用模式是次要的
>mikesun
>不是万能的，对于模式的应用还是要看具体的任务需要
No silver bullet... :P
因需(需求)而变(方案)
良好的方案允许需求持续变化
>kewan
>更深入的关注问题的本质
>而使用模式，不是模式本身的的问题。
>使用模式是为了更好的理解系统，使用模式来描述系统，是为了可以在进行高级别的抽象。
>正确的方向是理解目标系统，而且越深越好。
>zhouwenfeng1428
>在设计中根据自己某种业务在决定运用某种模式,不能为了要用模式而用它
-----------
模式是成功经验的总结，适用有益。
正确理解模式有助于特定问题的解决——模式为我们提供思考的方向。
Change 和 Dependency 是模式的两大主题（也是软件设计要考虑的主要因素）。
而问题会因时而变，模式的使用也应该做到因问题而变。因此，深入理解问题本身是必需的。
对于UML,OO,Design Patterns....等，了解得越多，越有助于问题的解决，摆在面前的选择也越多。
要具体问题具体分析。
根据问题的实际择优而从，有时也需要综合多种模式的优级点，平衡各方面的需求。
解决问题毋需局限于模式的选择，而应放宽视野，有助于问题更好地解决的任何方法都应该放到被考虑的范围之内。
别忘了根本问题是：
您要解决问题本身，而不是解决问题的过程或其他（办法，思路……等），
当然，对解决过程、办法、思路……等的总结将有助于再度解决同类问题。
模式有助于问题（尽管问题一直变化）被 可持续地 正确地 解决。
----
一家之言，欢迎拍砖。
waker615@163.com
大家说的都非常精辟，非常喜欢这里的氛围
我是一个初学者，所以也没什么发言权