关于“设计模式”的一个问题

[victor]

俺在项目里面要用到一个软件结构，不知道用什么模式设计比较好些。：）
当初设计模式也学的不是很深，只好求助于各位大侠。

软件的大体功能是这样的：

有多种格式的数据要convert 到另外多种格式：

Fmt1 conv_mid conv_dest Fmt1
Fmt2 ---------------> mid_fmt ----------------> Fmt2
Fmt3 Fmt3
... ...

下面是我的思路：
我设计了两个converter类，类里面分别有一个函数:
class SrcConv:
def cnvt(self, src_data, mid_data):...
class MidConv:
def cnvt(self, mid_data, des_data):...

在cnvt这个函数里面肯定不能用
if src_data.fmt is Fmt1:...
elif src_data.fmt is Fmt2:...
...
或
if des_data.fmt is Fmt1:...
elif des_data.fmt is Fmt2:...
...

这种多重判断的结构，太不OO了，所以我想肯定有一种设计模式跟这种情况是对应的，
我是想用factory pattern来实现。
（1）把两个converter类变成虚基类，继承类每种conveter都有自己的实现，
这样每次new 一个converter，然后调用他的cnvt函数就可以了。
（2）写一个ConverterCreater基类，然后分别有ConvMidCreater和
ConvDestCreater继承这个基类，基类是这样定义的：

class ConverterCreater:
def creatConverter(self,format):
def convert(self,format,src,dest):
converter = self.creatConverter(format)
converter.cnvt(src,dest)

这样，如果有新的format增加，只要改两个ConverterCreater的继承类的creatConverter函数
再增加converter类就可以了。

不知道这样设计是不是好，感觉有点生搬硬套"factory 模式"，不知道有没有更好的设计，
或是有什么好的改进方法。。。

感谢各位大侠。。。

[Albert Lee]

2008/9/17 victor <hanh...@gmail.com>:

这些格式可以转换成一种通用格式么？比如 嵌套的 dict ，或者xml 之类的
用一个函数， convert(src_data, src_format, target_format)

里面用不着啥模式。

[victor]

嗯，就是先转换成一种通用的格式，然后再转换成其他的格式，
如果只写convert(src,target)这种样子的话，需要在函数里面写if scr_fmt == ...
这样写的函数就很大，很ugly，扩展性也不好。。。

On Sep 17, 1:31 pm, "Albert Lee" <hanzhup...@gmail.com> wrote:
> 2008/9/17 victor <hanha...@gmail.com>:

> 里面用不着啥模式。- Hide quoted text -
>
> - Show quoted text -

[Zoom.Quiet]

2008/9/17 victor <hanh...@gmail.com>:
> 嗯，就是先转换成一种通用的格式，然后再转换成其他的格式，
真的!整啥也甭整模式,那是OOP世界的东西,
Pythonic 不是,,,,

建议直接使用 protocol-buffers 或是 XML 或是JSON 等等标准数据交换支持,
完成之,,,

--

http://zoomquiet.org'''
过程改进乃是催生可促生靠谱的人的组织!
PE keeps evolving organizations which promoting people be good!'''

[Lanser]

不要为了实现模式而设计

其他开发人员一眼就能看懂if elif else结构
套用模式后呢

我认为开发人员之间的通畅的交流更重要些

2008/9/17 victor <hanh...@gmail.com>

--
Powered by interests.

[victor]

OOP和pythonic不冲突吧，感觉楼上将两个感念对立起来了，我觉得OOP很有用啊，有助于培养程序员的sense，呵呵
另外，protocol-buffers或XML适用于支持结构化的语言的，在这个case中，不同的fmt并不是很结构化。。。

On Sep 17, 1:46 pm, Zoom.Quiet <zoom.qu...@gmail.com> wrote:
> 2008/9/17 victor <hanha...@gmail.com>:> 嗯，就是先转换成一种通用的格式，然后再转换成其他的格式，

> PE keeps evolving organizations which promoting people be good!'''- Hide quoted text -

[victor]

如果一个function里面有并列十多个if elif,每个if 下面有几百行代码，那是不是就会让看代码的人
很痛苦呢？

> > - Show quoted text -- Hide quoted text -

[limodou]

2008/9/17 victor <hanh...@gmail.com>:

>
> 如果一个function里面有并列十多个if elif,每个if 下面有几百行代码，那是不是就会让看代码的人
> 很痛苦呢？
>

source = {'Fmt1':Fmt1class, 'Fmt2':Fmt2class, ...}
des = {'Fmt1':Fmt1class, 'Fmt2':Fmt2class, ...}

def convert(s, d):
mid = source[s.fmt].convert()
return mid.convert_to(d.fmt)

示例代码。没有出错判断。

--
I like python!
UliPad <<The Python Editor>>: http://code.google.com/p/ulipad/
UliWeb <<simple web framework>>: http://uliwebproject.appspot.com
My Blog: (new)http://http://hi.baidu.com/limodou
(old)http://www.donews.net/limodou

[victor]

我也在想是不是把convert当作一个函数写到source里面会好一点，，，

On Sep 17, 2:14 pm, limodou <limo...@gmail.com> wrote:
> 2008/9/17 victor <hanha...@gmail.com>:

[Zoom.Quiet]

2008/9/17 victor <hanh...@gmail.com>:
> 我也在想是不是把convert当作一个函数写到source里面会好一点，，，
>
嗬嗬嗬，老 duck 了，，，

> On Sep 17, 2:14 pm, limodou <limo...@gmail.com> wrote:
>> 2008/9/17 victor <hanha...@gmail.com>:
>>
>>
>>
>> > 如果一个function里面有并列十多个if elif,每个if 下面有几百行代码，那是不是就会让看代码的人
>> > 很痛苦呢？
>>
>> source = {'Fmt1':Fmt1class, 'Fmt2':Fmt2class, ...}
>> des = {'Fmt1':Fmt1class, 'Fmt2':Fmt2class, ...}
>>
>> def convert(s, d):
>> mid = source[s.fmt].convert()
>> return mid.convert_to(d.fmt)
>>
>> 示例代码。没有出错判断。

--

http://zoomquiet.org'''

[limodou]

2008/9/17 victor <hanh...@gmail.com>:

> 我也在想是不是把convert当作一个函数写到source里面会好一点，，，
>
> On Sep 17, 2:14 pm, limodou <limo...@gmail.com> wrote:
>> 2008/9/17 victor <hanha...@gmail.com>:
>>
>>
>>
>> > 如果一个function里面有并列十多个if elif,每个if 下面有几百行代码，那是不是就会让看代码的人
>> > 很痛苦呢？
>>
>> source = {'Fmt1':Fmt1class, 'Fmt2':Fmt2class, ...}
>> des = {'Fmt1':Fmt1class, 'Fmt2':Fmt2class, ...}
>>
>> def convert(s, d):
>> mid = source[s.fmt].convert()
>> return mid.convert_to(d.fmt)
>>
>> 示例代码。没有出错判断。

我的示例代码不就是吗？每个Fmt类都有自已的convert()方法。上面的代码还可以处理为：

def convert(s, d):
mid = source[s.fmt].convert()

return des[d.fmt].convert(mid)

[yi gong]

表驱动

2008/9/17 victor <hanh...@gmail.com>

[katkat lim]

貌似模式是重构出来的。。。不是一开始就能设计出来的。。。

啥叫表驱动？

 

 

2008/9/17 yi gong <topi...@gmail.com>

[victor]

不需要 不靠谱＋热情＋好奇 的答案。。。
需要 靠谱＋学过OO＋认真思考 的答案。。。

On Sep 17, 3:09 pm, "yi gong" <topika...@gmail.com> wrote:
> 表驱动
>
> 2008/9/17 victor <hanha...@gmail.com>

> > 感谢各位大侠。。。- Hide quoted text -

[yi gong]

>> source = {'Fmt1':Fmt1class, 'Fmt2':Fmt2class, ...}
>> des = {'Fmt1':Fmt1class, 'Fmt2':Fmt2class, ...}

 

这玩意就是表驱动.

 

不过我就搞不明白,为什么那么邪乎的要用个class

直接一堆function不好么?反正python里function也是first class object.

 

 

2008/9/17 katkat lim <limk...@gmail.com>

[yi gong]

神啊,

俺一向认为work的软件要比OO重要的多.
再说了,我也没有怎么着你,还给你带了硕大一顶帽子,怎么我就不靠谱了?

 

2008/9/17 victor <hanh...@gmail.com>

[victor]

呵呵，误会，纯属误会。。。
我还是很认同你中间的那句话的

On Sep 17, 3:32 pm, "yi gong" <topika...@gmail.com> wrote:
> 神啊,
> 俺一向认为work的软件要比OO重要的多.
> 再说了,我也没有怎么着你,还给你带了硕大一顶帽子,怎么我就不靠谱了?
>

> 2008/9/17 victor <hanha...@gmail.com>

> > > - Show quoted text -- Hide quoted text -

[Albert Lee]

2008/9/17 victor <hanh...@gmail.com>:

先把设计模式忘掉吧。

[yuting cui]

2008/9/17 Albert Lee <hanzh...@gmail.com>:
>
> 先把设计模式忘掉吧。
>
呃...不明白为什么这么多人讨厌设计模式...设计模式就像uml一样，是给设计人员交流之间提供了一种共同的符号，减少的交流中表意不清造成的代价。
当然...这东西不能乱用，你不能为了设计模式而设计模式，在处理实际问题的时候，设计模式只是提供了一个参考，你需要按照你的需求去考虑一个合理的实现，在这过程中可能会在某些基础的设计模式上做出改变，甚至彻底抛弃所有已知的设计模式做出一种全新的模式。在这个过程中设计模式的作用就是像数据结构和算法对具体实现的作用一样，只是对你的设计起一个参考模式，让你不至于无从下手，还有就是让你在和别人讨论的时候有一个方便的参考（"我这个设计是参考了工厂模式，提供了函数
xxx 作为创建方法，类 aaa、bbb作为实现类，他们都要提供
iii接口。"这种说法总比"我这个设计是这样的，里面有类aaa、bbb，他们的都有
ccc、ddd...方法，这些方法的作用是...，然后我做了一个函数xxx，你给定v1、v2作为参数，这个函数会根据...返回...，然后这些...可以用来..."这种说法要来的直观的多。）

具体到楼主这个问题，基本需求就是要进行数据的格式转换，如果数据格式有很多，而且可能会需要后期的增加。在这种情况下，需要转换可以尽量容易的增加对新格式的支持，那么采用工厂模式是非常合适的。

需求上我们先考虑对一个数据格式，我们要实现哪些功能，来确定一个新增数据格式工作量最小的需求，每个格式提供这些功能即可。

那么在实现上就非常简单了
首先是对每个确定每个数据格式都要求实现的接口（认为所有格式都是可以和中间格式相互转化的，这个在实际中显然不满足。）
这个接口的实现在Python中可以以类或者模块的方式来实现，看转化过程的需求（比如调用之间有必须保存的中间量那么为了线程安全的考虑，最好用类来实现）。
一个简单的实现如下
def isFormat(data):
...
def convertFromThisFormat(data,**kwargs):
...
def convertToThisFormat(middata,**kwargs):
...

然后就是工厂函数的实现（这个里面增加了对数据是否是指定格式的判定）
def formatFactory(fmt, data=None):
if data is None:
return fmt
if fmt.isFormat(data):
return fmt
else:
raise FormatError, ...

后面直接调用formatFactory返回的fmt的两个转化函数就行了

如果可以通过数据保证每个数据都只属于某一特定格式，那么我们甚至可以实现一种自动判定数据格式的工厂:

_fmts = []
... #从指定目录导入每种格式的模块，并把这个模块加入到_fmts中
def autoFormatFactory(data):
for fmt in _fmts:
if fmt.isFormat(data):
return fmt
raise UnknownFormatError

在这个过程中，所有已存在的格式模块没有任何的改动。

当然了，由于我也不清楚你的具体需求，所以工厂模式也有可能不适合你的应用，这个就得具体情况具体分析了。

[黄毅]

考虑 字符串 和 unicode 之间的这种关系

 

def encode_fmt1(midi_fmt_data):

    return fmt1_data

 

def decode_fmt1(fmt1_data):

    return midi_fmt_data

 

...

 

encoders = {

    fmt1: encode_fmt1,

    ...

}

 

decoders = {

    fmt1: decode_fmt1,

    ...

}

 

def transform(data, fmt_from, fmt_to):

     encoder = encoders[fmt_from]

     decoder = decoders[fmt_to]

     return encoder(decoder(data))

 

 

2008/9/17 victor <hanh...@gmail.com>

[Zoom.Quiet]

2008/9/18 黄毅 <yi.cod...@gmail.com>:

> 考虑 字符串 和 unicode 之间的这种关系
>

足够了，收录在:
http://wiki.woodpecker.org.cn/moin/MiscItems/2008-09-18

--

[wangmao]

2008/9/17 yuting cui <yuti...@gmail.com>

2008/9/17 Albert Lee <hanzh...@gmail.com>:
>
> 先把设计模式忘掉吧。
>
呃...不明白为什么这么多人讨厌设计模式...设计模式就像uml一样，是给设计人员交流之间提供了一种共同的符号，减少的交流中表意不清造成的代价。

我想Albert Lee的意思应该是不要为了设计模式而设计模式。

[头太晕]

2008/9/18 wangmao <lwm...@gmail.com>

我想Albert Lee的意思应该是不要为了设计模式而设计模式。

有道理。

不要为了OO而OO。

[fluke.l]

头太晕 wrote:
>
>
> 2008/9/18 wangmao <lwm...@gmail.com <mailto:lwm...@gmail.com>>
>
> 我想Albert Lee的意思应该是不要为了设计模式而设计模式。
>
>
> 有道理。
>
> 不要为了OO而OO。
总之，不要为了做一件事而做一件事:)
>
>
> >

[Albert Lee]

2008/9/18 头太晕 <tor...@gmail.com>:

其实我不是这个意思……

[limodou]

>>
>> 不要为了OO而OO。
> 总之，不要为了做一件事而做一件事:)

这句话说得好。设计模式主要的一个好处就是减少重复，而上面的话是同样的道理。只要是想到这一点，模式不模式的就无所谓了。

[LaiYonghao]

我想，设计模式有两个好处，一是为开发提供一个模板，让人可以照葫芦画瓢；二是让开发人员之间建立一些抽象的协议（又称行话），方便沟通。

DPs 是好东西，只是不可滥用。楼主已经觉得自己的代码（或设计）有问题，希望用 DPs 来解决，态度和手段都很对的，大家为什么要诋毁 DPs 呢？

2008/9/18 limodou <lim...@gmail.com>

--
http://blog.csdn.net/lanphaday
-------------------------------------------
用 C++ 的时候盯着 python，用 python 的时候盯着 C++。

[hansir]

俺写了一个简单的程序，不用class，
当然你也可以把它改为class的方式，不过那是java的处理方法。
其实module本身也是object,在python中一切都是object,所以直接写function的方式也是oop，
不过是oop在python中的实现罢了，从java转到python很久才慢慢明白这些。

在python中实现某些设计模式是非常简单的，因为python是动态语言。


def convert1(srcdata):
return 'conver1:'+srcdata

def convert2(srcdata):
return 'conver2:'+srcdata

def convertMD(srcdata,fmt):
'''middle function'''
return fmt(srcdata)

def convert(srcdata,fmt):
mddata = convertMD(srcdata, fmt)
mddata = 'final data:' + mddata
print mddata


convert('test',convert1)

[boost...@googlemail.com]

object != OOP
让这么多方法背这同样的参数不累吗?

[hansir]

object != oop, 但是object是oop的核心。

我写的只是表达一种模式在python中的实现， 其重点在于function,module或者class都可以作为一个普通的object使用，
至于细节的参数传递，那是可以根据实际情况进行调整，比如可以作为class的一个属性之类。

On 9月19日, 上午3时16分, "boostpy2...@yahoo.com.cn"

[Albert Lee]

2008/9/19 hansir <hamle...@gmail.com>:

动态语言有自己的模式， 硬套OOP那套模式会很别扭的。尤其是java上的一些模式，根本就是因为语言局限所以才搞的那么麻烦，很多那些模式在python这类语言中根本用不上。所以不要为"我为什么没能把23种模式都用上？"
这种问题而苦恼。

[Zoom.Quiet]

2008/9/19 Albert Lee <hanzh...@gmail.com>:

> 2008/9/19 hansir <hamle...@gmail.com>:
>> object != oop, 但是object是oop的核心。
>>
>> 我写的只是表达一种模式在python中的实现， 其重点在于function,module或者class都可以作为一个普通的object使用，
>> 至于细节的参数传递，那是可以根据实际情况进行调整，比如可以作为class的一个属性之类。

...

>
> 动态语言有自己的模式， 硬套OOP那套模式会很别扭的。尤其是java上的一些模式，根本就是因为语言局限所以才搞的那么麻烦，很多那些模式在python这类语言中根本用不上。所以不要为"我为什么没能把23种模式都用上？"
> 这种问题而苦恼。

好比拿着辞海不一定写得出红楼梦,
对特定事务/情景的特定解决模式,不能期待可以普适的解决我的相同事务/情景问题,,,因为其它因素太多了,,
设计模式,应该多看,体会人家解决问题的思路,其它的,甭在意了,,,

[Chuan Qin]

2008/9/19 Albert Lee <hanzh...@gmail.com>

动态语言有自己的模式， 硬套OOP那套模式会很别扭的。尤其是java上的一些模式，根本就是因为语言局限所以才搞的那么麻烦，很多那些模式在python这类语言中根本用不上。所以不要为"我为什么没能把23种模式都用上？"
这种问题而苦恼。

说得真好，赞同。罗罗嗦嗦一大堆，还不如用python几句搞定爽。

[victor]

听了大家的讨论，觉得自己的问题已经上层次了。。。呵呵

好吧，我发表一下自己对设计模式的看法

我觉得设计模式很"博大精深"，是很"靠谱"的东西，特别是当你用面向对象的思想设计大型软件的时候，不管你用什么语言实现，很多模式都可以用上，而且
确实可以方便很多，好处我就不多说了。
但是学习设计模式有一个很高的门槛，只有当你很深入理解其原理以及为什么要用这个模式，有什么好处的时候才能用的得心应手，披荆斩棘，快速解决设计，开
发中的很多问题。否则的话用这把双刃剑只能伤了自己，就像是高级的内功，在一开始练习的时候往往会走火入魔。而这些人往往就会觉得这种武功不入流，不好
用，不如一些"快餐技术"来的方便。

总之，如果你想快速解决小规模的问题，可能用不上什么模式，但是如果你要做一个architecture，不用模式很难开发出好的OO软件。

On Sep 19, 10:18 am, "Albert Lee" <hanzhup...@gmail.com> wrote:
> 2008/9/19 hansir <hamlet....@gmail.com>:

> 动态语言有自己的模式， 硬套OOP那套模式会很别扭的。尤其是java上的一些模式，根本就是因为语言局限所以才搞的那么麻烦，很多那些模式在python这类语言中根本用不上。所以-不要为"我为什么没能把23种模式都用上？"
> 这种问题而苦恼。- Hide quoted text -

[Albert Lee]

2008/9/19 victor <hanh...@gmail.com>:

把简单问题做成大框架不是能力的体现。

[刘鑫]

软件就是软件，干嘛一定要OO软件……

2008/9/19 victor <hanh...@gmail.com>

听了大家的讨论，觉得自己的问题已经上层次了。。。呵呵

好吧，我发表一下自己对设计模式的看法

我觉得设计模式很"博大精深"，是很"靠谱"的东西，特别是当你用面向对象的思想设计大型软件的时候，不管你用什么语言实现，很多模式都可以用上，而且
确实可以方便很多，好处我就不多说了。
但是学习设计模式有一个很高的门槛，只有当你很深入理解其原理以及为什么要用这个模式，有什么好处的时候才能用的得心应手，披荆斩棘，快速解决设计，开
发中的很多问题。否则的话用这把双刃剑只能伤了自己，就像是高级的内功，在一开始练习的时候往往会走火入魔。而这些人往往就会觉得这种武功不入流，不好
用，不如一些"快餐技术"来的方便。

总之，如果你想快速解决小规模的问题，可能用不上什么模式，但是如果你要做一个architecture，不用模式很难开发出好的OO软件。

--
Python 官方入门文档：Python Tutorial 简体中文版

http://wiki.woodpecker.org.cn/moin/March_Liu/PyTutorial
……

劉鑫
March.Liu

[黄毅]

建议大家尽量用代码说话，呵呵，有什么想法直接写成代码吧，尤其这种问题，自然语言很难准确表达你的想法，更别提讨论了。

设计模式这个概念宽可宽到任何模式，python也可以有很多模式，窄也可以窄到四人帮那23个模式。大家显然在这点上没有达成共识。

 

总之，如果你想快速解决小规模的问题，可能用不上什么模式，但是如果你要做一个architecture，不用模式很难开发出好的OO软件。

 

这句话很有代表性。

不好意思，我又自然语言说多了，罪过罪过。。。大家继续批驳吧。

 

 

--
http://codeplayer.blogspot.com/

[Albert Lee]

2008/9/19 黄毅 <yi.cod...@gmail.com>:

> 建议大家尽量用代码说话，呵呵，有什么想法直接写成代码吧，尤其这种问题，自然语言很难准确表达你的想法，更别提讨论了。
> 设计模式这个概念宽可宽到任何模式，python也可以有很多模式，窄也可以窄到四人帮那23个模式。大家显然在这点上没有达成共识。
>
>>
>> 总之，如果你想快速解决小规模的问题，可能用不上什么模式，但是如果你要做一个architecture，不用模式很难开发出好的OO软件。
>
>
> 这句话很有代表性。

典型的 myth

[罗*]

如果要用到模式设计,我觉得Decorator模式比factory模式更好一些.

这样对于重构,我觉得更好一些

[yuting cui]

2008/9/19 罗* <heido...@gmail.com>:
> 如果要用到模式设计,我觉得Decorator模式比factory模式更好一些.
>
> 这样对于重构,我觉得更好一些
>
捶桌子中...