怎么理解设计模式

08-08-28 huajunting
小弟是个学生蛋子,没什么特别大能耐。最近捧着设计模式看,看过一遍后发现还是难以理解它的思想方法。很多模式感觉就是表面功夫,思路还是打不开。

比如很多模式就感觉是个聚合关系:适配器,桥梁多是将目标桥接一样,放到另外的一个接口去工作。

请教各路高手如何学好设计模式啊?尤其是掌握它的真谛。谢谢

ITfuture
2008-09-03 08:45
实践才是检验真理的惟一标准啊~~~

我目前也在看模式.我觉得首先要有概念意识.懂得模式在什么情况下用.他要面向处理的问题的点是什么.接下来就是实践了...

学习ing

ITfuture
2008-09-03 08:45
实践才是检验真理的惟一标准啊~~~

我目前也在看模式.我觉得首先要有概念意识.懂得模式在什么情况下用.他要面向处理的问题的点是什么.接下来就是实践了...

学习ing

freebox
2008-09-03 10:06
模式是从大量的应用场景中总结出来,并且要重新应用回类似的场景的东西。

比如IDE提供的java代码编写,有大括号放在哪的问题,有直接跟在第一行后面,不换行,有另起一行写。这里面就可以认为有两个模式,不妨分别叫做“括号紧缩模式”和“括号独立模式”

于是当大家都熟悉这两个名词的意义的时候,以后写代码时只要有一个人说,我们应该用“括号紧缩模式”编写,大家就都知道他在说什么,并且能够照着做。这就简化了人们交流当中使用的语言,因为我们不必再用长长的一段话来解释一次什么才是“括号紧缩”,只用这个短语就能表达了。

然后要求这种场景必须多次出现。写代码这种场景就会多次出现。而对于有些东西,虽然这次解决得不错,但是那是几辈子才碰上一次的事让我不小心碰上了,虽然解决方案不错,但不能做为模式使用,因为它不会反复出现。像丢番都解不定方程整数解似的,他每次都给一个巧妙的方法解决,却从没有一个问题的解法能够重用即便这两个方程非常类似。他的方法就不能做模式使用,而中国的剩余定理就能够解决一批同余问题,所以做为定理提了出来,就能当模式使用。所以说一定要有反复出现的场景,没有场景就没有模式。

模式可以被认为是一种在特定上下文活动当中所使用的模板,比如大家用的SSH,大家都知道它是指spring,struts,hibernate,一但确认了我的应用要使用这种结构,我就对大家说我要使用SSH来完成,那大家就都知道要使用什么来做了,到底应该注意SSH的哪些方面是不用再解释一次的,比如我就不用再解释如何在Spring中配置bean以及如何结合spring和hibernate等等既枯燥又没有多大意义的问题,一个“SSH”这样的短语就能解释了。但是这里面是需要有上下文的,就是说我已经确定了我的应用是SSH结构。当我使用另一种结构比如说seam的时候,就不需要再解释SSH里的内容了,这是两种上下文,解决方案也不一样。

所说的23种设计模式也是如此,我不是全部了解,拿我了解的一部分来说说,比如说工厂,它封装了对象的创建过程,那就要知道在什么情况下需要用工厂,创建过程复杂的时候就要用工厂。创建过程复杂包括:不知道从一批子类中选哪个来创建,创建时依赖其它一些资源而这些本来不是和产品对象关系紧密的,等等。放进工厂里封装就是不错的方法,以后碰到类似的场景(创建过程复杂),就都可以用工厂完成。

[该贴被freebox于2008-09-03 10:13修改过]

banq
2008-09-03 14:19
>以说一定要有反复出现的场景,没有场景就没有模式。

非常正确和重要,从freebox发言来看,模式和框架是想通的,我以前统称这样的思维为模式思维,一通百通。

当一个有经验的程序员将其经验上升为模式思维时,就达到一个新的层次,无论再出现什么新的技术和细节,他都能在很短时间内掌握其架构,甚至无需这方面的经验,这就是模式思维的威力。

猜你喜欢
2Go 1 2 下一页