怎么理解设计模式
比如很多模式就感觉是个聚合关系：适配器，桥梁多是将目标桥接一样，放到另外的一个接口去工作。
请教各路高手如何学好设计模式啊？尤其是掌握它的真谛。谢谢
比如很多模式就感觉是个聚合关系：适配器，桥梁多是将目标桥接一样，放到另外的一个接口去工作。
请教各路高手如何学好设计模式啊？尤其是掌握它的真谛。谢谢
我目前也在看模式.我觉得首先要有概念意识.懂得模式在什么情况下用.他要面向处理的问题的点是什么.接下来就是实践了...
学习ing
我目前也在看模式.我觉得首先要有概念意识.懂得模式在什么情况下用.他要面向处理的问题的点是什么.接下来就是实践了...
学习ing
比如IDE提供的java代码编写，有大括号放在哪的问题，有直接跟在第一行后面，不换行，有另起一行写。这里面就可以认为有两个模式，不妨分别叫做“括号紧缩模式”和“括号独立模式”
于是当大家都熟悉这两个名词的意义的时候，以后写代码时只要有一个人说，我们应该用“括号紧缩模式”编写，大家就都知道他在说什么，并且能够照着做。这就简化了人们交流当中使用的语言，因为我们不必再用长长的一段话来解释一次什么才是“括号紧缩”，只用这个短语就能表达了。
然后要求这种场景必须多次出现。写代码这种场景就会多次出现。而对于有些东西，虽然这次解决得不错，但是那是几辈子才碰上一次的事让我不小心碰上了，虽然解决方案不错，但不能做为模式使用，因为它不会反复出现。像丢番都解不定方程整数解似的，他每次都给一个巧妙的方法解决，却从没有一个问题的解法能够重用即便这两个方程非常类似。他的方法就不能做模式使用，而中国的剩余定理就能够解决一批同余问题，所以做为定理提了出来，就能当模式使用。所以说一定要有反复出现的场景，没有场景就没有模式。
模式可以被认为是一种在特定上下文活动当中所使用的模板，比如大家用的SSH，大家都知道它是指spring，struts，hibernate，一但确认了我的应用要使用这种结构，我就对大家说我要使用SSH来完成，那大家就都知道要使用什么来做了，到底应该注意SSH的哪些方面是不用再解释一次的，比如我就不用再解释如何在Spring中配置bean以及如何结合spring和hibernate等等既枯燥又没有多大意义的问题，一个“SSH”这样的短语就能解释了。但是这里面是需要有上下文的，就是说我已经确定了我的应用是SSH结构。当我使用另一种结构比如说seam的时候，就不需要再解释SSH里的内容了，这是两种上下文，解决方案也不一样。
所说的23种设计模式也是如此，我不是全部了解，拿我了解的一部分来说说，比如说工厂，它封装了对象的创建过程，那就要知道在什么情况下需要用工厂，创建过程复杂的时候就要用工厂。创建过程复杂包括：不知道从一批子类中选哪个来创建，创建时依赖其它一些资源而这些本来不是和产品对象关系紧密的，等等。放进工厂里封装就是不错的方法，以后碰到类似的场景（创建过程复杂），就都可以用工厂完成。
[该贴被freebox于2008-09-03 10:13修改过]
非常正确和重要，从freebox发言来看，模式和框架是想通的，我以前统称这样的思维为模式思维，一通百通。
当一个有经验的程序员将其经验上升为模式思维时，就达到一个新的层次，无论再出现什么新的技术和细节，他都能在很短时间内掌握其架构，甚至无需这方面的经验，这就是模式思维的威力。
我的学习路线:《设计模式》-->《banq设计模式》-->《设计模式解析-->《设计模式初学者指南》-->jive论坛代码--->jivejdon代码--->jdon框架代码-->《设计模式》
conclusion:灵活运用太难!!!
[该贴被oojdon于2008-09-03 14:36修改过]
你清楚了什么是变化的，什么是不需要变化的时候，运用起来就水到渠成了。
[该贴被bookview于2008-09-03 14:50修改过]
然后才一步一步引出模式