论坛首页 入门技术论坛

[讨论] 如何区别和理解理解设计模式 ?

浏览 17104 次
该帖已经被评为新手帖
作者 正文
   发表时间:2008-11-17  
sea7 写道
tianmo2008 写道
jeff.chuh 写道
tianmo2008 写道
这几天看书,工厂方法确实很不好理解,感觉没有必要,我的理解是引进工厂的目的之一是要是要隐藏掉new,但在工厂方法里,实现了工厂接口的具体工厂类自身也是要new的,这样,为什么不直接去new一个产品呢?而且和抽象工厂对比,我觉得工厂方法是定位在一个产品应该对应一个工厂类的,这样的话,没添加一个产品就得有对应的一个工厂,还得new一个工厂,这样还不如直接用产品接口,然后new一个具体产品不是更直观吗?工厂方法和接口感觉不到有什么优势.


你是没发现工厂用到什么地方,
当然对于ArrayList在代码里你可以到处new,
因为ArrayList的实现是稳定的,不需要你实现一个MyArrayList,
但是有些情况不一样,
比如有个FileLogger,从名字看出它是向文件输出log的实现类,
但你并不能保证你做好的项目以后不会变成向DB输出log,
这时你又实现了DBLogger,这时你发现FileLogger被new到各个地方,
你不得不一个个都替换成DBLogger。
而如果使用工程的话,你只需要修改工厂的实现就可以了,甚至你工厂是读取配置文件得到FileLogger的,
那么你只需要修改配置文件就可以了。

至于接口,你可以找找为什么要面向接口编程,这样做可以给你带来什么。

宏光点来看工厂模式的话,我是可以理解工厂的优势的,但现在是在工厂模式里面细分简单工厂、工厂方法和抽象工厂的时候,我个人觉得工厂方法在简单工厂和抽象工厂之间成了鸡肋,简单工厂和抽象工厂我都可以找到他们的应用场合,但工厂方法我却找不到,因为我目前接触的需求,要么就直接用简单工厂了事(尤其在配合反射的情况下),要么就直接分类后用抽象工厂,而没有考虑工厂方法的地方,所以觉得工厂方法很不好理解。
注意,我只是冲着工厂方法,而不是冲着整个工厂模式。


有这样一个case,现在你需要有一个生产某种品牌电脑的factory,请问你会使用简单工厂吗?
如果你使用简单工厂,那要是有一天有一个新的品牌的电脑呢??这个时候你需要怎么办??


简单工厂加反射,很强大.
0 请登录后投票
   发表时间:2008-11-17  
简单工厂封装new XXX()到一个地方,便于修改.
工厂方法封装new XXX()到一个地方,便于扩展.
0 请登录后投票
   发表时间:2008-11-17  
H_eaven 写道
sea7 写道
tianmo2008 写道
jeff.chuh 写道
tianmo2008 写道
这几天看书,工厂方法确实很不好理解,感觉没有必要,我的理解是引进工厂的目的之一是要是要隐藏掉new,但在工厂方法里,实现了工厂接口的具体工厂类自身也是要new的,这样,为什么不直接去new一个产品呢?而且和抽象工厂对比,我觉得工厂方法是定位在一个产品应该对应一个工厂类的,这样的话,没添加一个产品就得有对应的一个工厂,还得new一个工厂,这样还不如直接用产品接口,然后new一个具体产品不是更直观吗?工厂方法和接口感觉不到有什么优势.


你是没发现工厂用到什么地方,
当然对于ArrayList在代码里你可以到处new,
因为ArrayList的实现是稳定的,不需要你实现一个MyArrayList,
但是有些情况不一样,
比如有个FileLogger,从名字看出它是向文件输出log的实现类,
但你并不能保证你做好的项目以后不会变成向DB输出log,
这时你又实现了DBLogger,这时你发现FileLogger被new到各个地方,
你不得不一个个都替换成DBLogger。
而如果使用工程的话,你只需要修改工厂的实现就可以了,甚至你工厂是读取配置文件得到FileLogger的,
那么你只需要修改配置文件就可以了。

至于接口,你可以找找为什么要面向接口编程,这样做可以给你带来什么。

宏光点来看工厂模式的话,我是可以理解工厂的优势的,但现在是在工厂模式里面细分简单工厂、工厂方法和抽象工厂的时候,我个人觉得工厂方法在简单工厂和抽象工厂之间成了鸡肋,简单工厂和抽象工厂我都可以找到他们的应用场合,但工厂方法我却找不到,因为我目前接触的需求,要么就直接用简单工厂了事(尤其在配合反射的情况下),要么就直接分类后用抽象工厂,而没有考虑工厂方法的地方,所以觉得工厂方法很不好理解。
注意,我只是冲着工厂方法,而不是冲着整个工厂模式。


有这样一个case,现在你需要有一个生产某种品牌电脑的factory,请问你会使用简单工厂吗?
如果你使用简单工厂,那要是有一天有一个新的品牌的电脑呢??这个时候你需要怎么办??


简单工厂加反射,很强大.

也许这样是可以实现,但你是否想到性能,反射必须会影响性能,而此时使用工厂方法则更为恰当,我们不只是要解决问题,而是要用最合理的方式解决问题.
0 请登录后投票
   发表时间:2008-11-17  
H_eaven 写道
版主把这贴给删除了,
发错了.



不明白你的意思???
0 请登录后投票
   发表时间:2008-11-17  
设计模式 个人觉得没必要学,记得前几个月我还不知道它是什么东西,但是整天在同事口里听到它,后来找来资料一看,原来这模式在项目中大部分都用过,只是不知道它的专业术语而已,现在看到有人整天把设计模式挂在嘴边,我不想多说什么,模式重在理解和实践中的体会,难道照着书本写几个例子就能弄懂设计模式吗?

时机到了,自然就懂了..
0 请登录后投票
   发表时间:2008-11-18  
Ivan_Pig 写道
书看了有两遍,感觉还是很肤浅。
我直到项目开发,才体会到设计模式的用途,感觉看书看不出什么来。

正解啊。
另外,gof书上的那些代码是经典,但不是说在项目里用各种语言去实现。实际应用中还是可以变通一下的。不要太教条!
0 请登录后投票
   发表时间:2008-11-19  
sea7 写道
H_eaven 写道
sea7 写道
tianmo2008 写道
jeff.chuh 写道
tianmo2008 写道
这几天看书,工厂方法确实很不好理解,感觉没有必要,我的理解是引进工厂的目的之一是要是要隐藏掉new,但在工厂方法里,实现了工厂接口的具体工厂类自身也是要new的,这样,为什么不直接去new一个产品呢?而且和抽象工厂对比,我觉得工厂方法是定位在一个产品应该对应一个工厂类的,这样的话,没添加一个产品就得有对应的一个工厂,还得new一个工厂,这样还不如直接用产品接口,然后new一个具体产品不是更直观吗?工厂方法和接口感觉不到有什么优势.


你是没发现工厂用到什么地方,
当然对于ArrayList在代码里你可以到处new,
因为ArrayList的实现是稳定的,不需要你实现一个MyArrayList,
但是有些情况不一样,
比如有个FileLogger,从名字看出它是向文件输出log的实现类,
但你并不能保证你做好的项目以后不会变成向DB输出log,
这时你又实现了DBLogger,这时你发现FileLogger被new到各个地方,
你不得不一个个都替换成DBLogger。
而如果使用工程的话,你只需要修改工厂的实现就可以了,甚至你工厂是读取配置文件得到FileLogger的,
那么你只需要修改配置文件就可以了。

至于接口,你可以找找为什么要面向接口编程,这样做可以给你带来什么。

宏光点来看工厂模式的话,我是可以理解工厂的优势的,但现在是在工厂模式里面细分简单工厂、工厂方法和抽象工厂的时候,我个人觉得工厂方法在简单工厂和抽象工厂之间成了鸡肋,简单工厂和抽象工厂我都可以找到他们的应用场合,但工厂方法我却找不到,因为我目前接触的需求,要么就直接用简单工厂了事(尤其在配合反射的情况下),要么就直接分类后用抽象工厂,而没有考虑工厂方法的地方,所以觉得工厂方法很不好理解。
注意,我只是冲着工厂方法,而不是冲着整个工厂模式。


有这样一个case,现在你需要有一个生产某种品牌电脑的factory,请问你会使用简单工厂吗?
如果你使用简单工厂,那要是有一天有一个新的品牌的电脑呢??这个时候你需要怎么办??


简单工厂加反射,很强大.

也许这样是可以实现,但你是否想到性能,反射必须会影响性能,而此时使用工厂方法则更为恰当,我们不只是要解决问题,而是要用最合理的方式解决问题.



反射 在框架中无处不在。spring struts 等等都使用了反射。到目前为止,反射对性能的影响,也没怎么考虑了。

服务器,不会还用上几代的吧

0 请登录后投票
   发表时间:2008-11-19  
我学习设计模式的方法是不急着去看代码,而是先理解他的定义,在网上查找此设计模式的使用场合.因为设计模式而言,本身就应该是脱离代码层面的.

但是学习了一段时间以后我就放弃,因为说实在的,实在没有意义.为了设计模式而设计模式不可取.
0 请登录后投票
   发表时间:2008-11-20  
我觉得看看书 了解下设计模式的大概几个就行了
然后在自己工作中设计类的时候 想想自己的需求和目的 然后套套设计模式
多用用几次就自然而然全理解了
0 请登录后投票
   发表时间:2008-11-21  
我是个新入行者,对设计模式也是了解不理解,因为没用过,或者说没看过别人项目里面使用的设计模式,如果自己用过或者说是见过的话我自信自己能够理解。实践出真知一点不错。
0 请登录后投票
论坛首页 入门技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics