UML软件工程组织

模式设计与形式主义
转载自 netwind (往事如风)

 

7月13日到上海,16日开始上班,到现在将近两个月了,感觉还是挺充实的,甚至有点累,可能是我给自己加了太多的任务,定下太高的目标,真的好累,我决定要好好休息一段时间,顺便把个人主页更新一下,否则chinaren就要把我踢出去了.


其实今年以来一直没怎么写代码,也就是上半年3月-4月之间写过一段时间,东西都忘得差不多了。基础不牢的后果很快体现出来,以前图方便一般用的是MFC,好多Windows的特性都是一知半解甚至一点都不清楚,上个月开始重新用VC++的时候真有点一筹莫展的感觉,代码改来改去,总是不理想或存在bug,那个时候我很想去买一本houjie写的《MFC深入浅出》彻底学学MFC的,后来一想算了,MFC即使还没有到灭亡的时候,我现在也对WINDOWS环境下的编程深恶痛绝,我渴望能在一个非常自由的环境下做一些贴近底层的、有挑战性的工作,而不仅仅是懂得搭积木式的coding,于是我打消了买书的念头,老老实实的捧着《Thinking in C++》看了起来。


前不久认识了一位在公司工作了三年的朋友,他也是一位coding好手,有一次和他讨论软件内部各个模块如何组织的问题,收获挺大的。

先说我的看法吧,今年初我开始持一种在软件开发中采用类似于MS DNA结构开发模式的观点,把软件内部的各个模块分为表现层,逻辑层,数据层(注意:我说的只是一个软件内部各个C++类的组织形式,而不是一个大型系统方案的结构,大型系统方案当然都会采用三层结构),这是当时我看三星的基站网管软件文档忽然得来的一个想法。那时候我挺激动的,想着自己经历了一年多的coding生活,总算由量变到达质变,我先是在水木清华软件工程版或者是VISUAL C++版或者是Programming版上抛出这个论点,马上有网友响应我这个观点,后来好像还收进了精华区(hehe,记不清了,找不到不要骂我哦),然后我开始动手把去年底在教研室做的一个GPS-GSM车载终端监控软件按照这个思路重写一遍,把所有的逻辑处理从各种各样的View/Wnd/FrameWnd里抽离出来,形成写成一个个专用于逻辑处理的类,与文件存储有关的则被我归结到数据层上去,与用户界面有关的当然就是表现层了,这样一来,整个软件结构显得清晰很多,代码易读很多。

写完那个软件之后,我对这个想法愈加深信,我开始全面的在自己的软件开发中通盘考虑这种做法,甚至有些过了头走向极端。有一段时间,我无论拿到什么样的project都要从三层上来考虑,A层负责与用户交互,B层负责逻辑处理,C层负责数据存储,几个逻辑模块B1,B2,B3之间还存在一个通信队列,B1负责写队列,B2负责读队列......一开始我就把一个小软件的框架设计得非常庞大吓人,到了动手开始写代码后,我发现自己渐渐无法控制代码了,尽管开始我认为自己的软件结构定的很好了,但还是有很多意想不到的事情,一方面是实际情况很复杂,并不是我设计那么几个表现层、逻辑层、数据层所能解决的;另一方面是过于追求模式,什么样的东西都往三层上套,一个很小的功能,一个类就能解决的,我很硬性的分为两/三层结构,用了好几个类,尽管每个类只有一两个函数,而且这几个类之间的功能并不象所谓的三层那样区别非常明显......我热衷于模式设计,却陷入了形式主义。


有天晚上,我把自己的这个想法和那位同事交流了一下,他和我的想法差别较大,在软件内部模块组织上,他不象我那样非要以某种模式来组织软件,他并不看重软件内部模块划分的是否鲜明,他只是讲究某个类所实现的功能具备好的内聚性和耦合性,比如一个属性表,要是以我的想法,必定是一个专管逻辑处理的类,负责判断用户设置了那些属性,把这些属性存储到那个设置文件中,然后再把结果返回到表现层以反馈给用户;而我的同事的想法非常直接,就是一个类,既用于界面表现又用于逻辑处理,他认为这个类的最小功能单位就是这个,没必要再分了。又比如我写了一个显示实时曲线的模块,需要把它给别的用户用,我的第一想法就是只给用户一个逻辑接口,负责计算坐标,添加实时数据,然后用户要通过这个接口去绘图,不再另外给用户与表现层的接口绘图,我的理由是接口功能统一便于编程。我的同事对此表示不解,他认为,这个功能模块就是一个实时曲线窗口,让用户直接从这个窗口类派生出自己的类,用户想干什么就干什么,这样更好。

我开始有点赞同他的想法了,我觉得自己的问题在于有时把软件划分的过于复杂,软件设计的目的之一在于划分好清晰的功能模块,而我却为了所谓的模式把功能分得过细,七零八落的,我们开发的目的是实现软件的功能而不是为了设计模式。不过话又说回来,我觉得这可能是另一方面的原因,并不一定是自己追求设计模式的错,再过一段时间,一年或者两年,再回过头看看,也许认为这种做法是对的,这种模式是对的,只不过自己在编码经验上不足。我一直认为,一个成功的软件就是应该在设计阶段严谨、规范、全面,框架定的大,正表明考虑周到,目前遇到这么多的问题只是因为经验有限,或者说这是必然的,我想经验再丰富的编码人员也不可能面面俱到。




版权所有:UML软件工程组织