我也是初学者，每天在这看很多人对模式的理解和看法。收获很多，但我并不认为初学者就没有发言权。只要你对这问题有自己的想法，你就可以拿来分享。这是发表自己想法的地方，不是等级森严的皇宫。

我倒是觉得楼主的理解有问题。可能很多人都是从单例和工厂开始学习设计模式的，但要说用到最多的是这两个模式，我不敢苟同，如果你使用某些框架就会发现，人家已经帮你搞定了！呵呵，我在思考在ejb3环境下到底还有必要自己写工厂吗？有必要写单例吗？似乎不必。

我的理解是如果大家能把代码写到良好的扩展性，维护性，低耦合，不用GoF模式也行呀，自己发明新的模式

一切都是接口,
一切皆为对像.
对像来源于抽像
抽像来源于思考

buaawhl写的这个多列排序问题很经典，我还没有实现看看到底是什么样，以前遇到这种多条件问题就感到很头疼，我都用很笨的法子，一个条件一段代码去实现

在我看来，模式是OO的助手。我们谈OO，但并不是为了OO而OO。大家都知道OO能给我们带来什么，但是我们做的项目却完全OO吗？这时一些助手就出来了，就如设计模式，就是OO一个强力的助手！
模式的应用让我们解决了一些我们想要用的功能但一时没有好点子的问题，因此我把模式看得更艺术化，是OO的助手。

我理解是这样的:
模式是什么?是对客观问题的抽象.
有人将软件开发模式分为3个层次:
架构模式 -> 设计模式 -> 实现模式
其中说的23个设计模式在第二个层次，然而一般的J2EE开发，几乎不用经历设计模式而直接机构模式-〉实现模式，因为太多的开源组件供你选择。
架构模式是在设计前期，或者概要设计要做的，制定了整个软件的整体基调，以及所用到的各种技术，如何分层等等问题，而设计模式受架构模式的制约，特定的设计模式经常活跃于特定的架构模式内。

>然而一般的J2EE开发，几乎不用经历设计模式而直接机构模式-〉实现模式

这个观点比较偏颇，在业务设计中，会大量使用设计模式，特别是按照Evans DDD来建模设计，业务都要在领域模型中实现，但是又不能将所有业务功能都塞到一个领域模型中，那么我们就要使用代理模式，桥模式等来巧妙设计领域模型。

下面这个DDD建模案例就是结合设计模式展开的。
http://www.jdon.com/article/34232.html

我认为设计模式就像是在平时描述问题的时候打比方，虽然OO和UML可以帮我们理解和交流很多问题，可是有些问题由于它的复杂性，并不是那么好理解和交流，而设计模式就像是一些很好地理解了问题的人打的一个简单的比方，然后别人遇到相似的问题的时候，拿它来交流就容易多了。
呵呵，我是个新手，很菜，不过也想表达下想法，不知道对不对，请各位多多指教。
[该贴被ulpyuoo于2009-01-09 23:10修改过]

老贴子怎么又翻出来了！！！

这个帖子------------炒作