|
再谈建模
在如何成为一个优秀的程序员二,我谈到了建模.在这里我再补充些想法.
在前面部分我谈到建模中一个常见的错误倾向: 试图建立起一个能够预知未来,包容万象的模块体系.这种好高骛远的建模方式常常导致三个后果:
1 开发工作被无限期拖延;
2 模块层次过于复杂,维护十分困难;
3 软件结构远远偏离了今天的实际需要,模块之间的访问和调用往往需要通过许多不必要的环节,直接影响了软件的运行速度.
接下来,我想谈谈建模中的另一个错误倾向:对现存设计模式的生搬硬套.上世纪九十年代Erich Gamma等人将設計模式(design pattern)理论引入了计算机科学领域.1995年Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides共 同撰写了:" Design Patterns -- Elements of Reusable Object-Oriented Software "一书.它的四位作者也被戏称为"四人帮"(Gang of Four 简称GoF).书中共收录了23个设计模式.此书一出,软件工业界如获至宝.很多人开口GoF闭口还是GoF.软件设计模式几乎成为计算机系学生最重要的 必修课之一.记得当时很流行的一种看法是:优秀的学生去建模,平庸的学生去编码.
事情真的这么简单吗?是不是只要把"四人帮"给我们提供的模式背得滚瓜烂熟,现实中的问题便可迎刃而解?
首 先我想从我个人的学习经验出发来谈谈我对这些设计模式的看法.我最初读GoF的书,是学生时代.当时没有多少编程经验,费了很大力气囫囵吞枣地把全书啃 完.但始终无法对这些设计模式有个清晰的认识,甚至觉得各种模式之间有很多互相矛盾之处,真的运用起来十分困难.当时正好实验室需要编写一个数据压缩程 序.我便趁机现炒现卖,想用自己刚学到的理论来指导实践.该数据压缩软件可以处理4种类型的数据:double, float, int, string.于是我便想当然地建立了四个模块:doubleCompress, floatCompress, intCompress, stringCompress.并且根据当时学的理论知识,运用了抽象工厂模式,单例模式等等.但事实上,不同类型的数据压缩的算法之间有着千丝万缕的关 系,结果导致我的模块之间的关系复杂,逻辑十分混乱.项目开发结果也就可想而知了.
后来有了一定的工作经验,特别是在进行了大量的编码之 后,再重读GoF的设计模式,感觉就完全不同了.不但对书中提到的各种设计模式的利弊有了清楚的认识,而且不无惊喜地发现,在具体的开发实践中,我已经不 知不觉地用上了许多GoF的设计模式了.那么我是如何在不自觉中找到这些设计模式的呢?回想起来,其实很简单.在开发和维护软件的过程中,我常常遇到一些 问题,比方说有些编码被多次重复使用;又比如由于模块之间的关系混乱,导致对某些模块的访问十分繁琐,且没有逻辑等等.这些问题不但使得软件的维护变得十 分困难,而且大大增加了软件出现漏洞的可能性.当这些问题变得越来越不可容忍的时候,我就想也许应该从软件结构上入手,换一种思维方式,重新设计模块.通 过这样一个不断思考优化改进的过程,GoF的设计模式便不请自来了.因此我认为优秀的设计模式是在对具体问题的不断思考,日积月累的编码实践中得来的.因 此这里我要再次重复我曾经提到的观点:建模不应该是程序开发初始阶段的一个单独僵硬的板块,它应该贯穿于整个开发过程中.建模应该始终和软件所要处理的具 体问题紧密联系在一起.一切从问题出发.寻找最简单最合理的设计模式.
|
|
