感觉大家缺少对模式的热情呀！！！！！！！！

通过重构得到模式，是我学习模式过程中受益最大的一句话！

国内现在的JAVA开发,多数是企业应用系统

技术层面要用设计模式的地方，都有Spring和Hibernate,工作流等等,人家使用了丰富的设计模式开发的现成产品

业务层面要不就是太简单，增删查改,复杂点的,很多就过程式编程解决，能够应用设计模式,对业务系统进行重构优化的,少之又少,加上工作流的支持,基本上都没有讨论的空间和必要性了,所以也就难怪讨论不流行了

同意

YES!
通过消除重复代码及其它BAD SMELL，终归会契合某种模式。
BTW,针对接口编程，至少工厂模式是跑不掉了 

优秀的设计思路　－> 设计模式

Domain Model －＞（经迭代，重构）　设计模式

模式已经深入骨髓了。常用的框架，没有哪一个是不用模式的，或者说依循模式的。

呵呵，我自己总结出一个SystemLoading pattern，已经在多个系统里面用过了。

每个系统在启动时都会有很多事情要做，看看你的程序启动过程是不是乱七八糟的？

项目启动时我会创建一个List,将所有的Task(实现ICommand)添加到List里面，然后再Iterative run所有task, 系统会有一个Session对象，每个task执行时可能会设置Session对象的一些参数，程序的后续运行会用到。这样做的话，系统启动就显得干净多了，后面再添加多少task，也不会把它搞脏。

企业应用系统，也分业务系统和中间件系统，业务系统小范围内还是有很多可以使用模式的地方，中间件系统就好玩点，它主要是以系统集成为目的，没有太多界面，做起来就比较OO了。不过国内很多公司的系统集成还在初级阶段（更多的现状可能是一个系统读数据库另外一个系统写数据库所谓的数据库层面的集成），二是自己做中间件系统代价比较高即使使用也更多倾向于使用厂商产品。

当然，我们先得学会使用现有的模式，然后在各自的领域创建自己的模式，当模式的成熟度高的时候，我们开发软件的工作效率和质量超高。
其实，模式不局限于设计，分析和整个开发过程中也有很多的模式，PLoP 中总结了很多与客户打交道的模式和项目组人员组织的模式。

我现在的感觉，越是业务复杂，OO就越能发挥作用，这可不仅仅是技术层面的。当然，OO跟模式无关。Gof的那些模式在ruby那里就没什么意义了。过程式编程可会很痛苦的。