沈豫龙 的blog

抽象程度思考

“软件设计的重点在于抽象”,不记得这句话是哪位说的了,我想改正一下:“保证软件灵活性设计的重点是抽象”,由此可知,抽象的作用是“保证软件的灵活性设计”。越来越多的语言、平台构建在OO思想之上,这充分说明了OO的正确性。OO,一种思想,一种谈到软件设计时必须涉及的思想,越来越多的人开始追捧它,当然,我也是其中之一。有了它,软件设计可以提升到一个“美”的境界;有了它,软件的可读性、可维护性、灵活性、可扩展性等等一大堆的“性”得到了很大的提高。为什么会这样?因为面向对象思想把软件跟现实更紧密地联系了起来,便得一些现实物理世界中的思想可以很容易的运用到软件中去。这几年,“设计模式”、“架构”等等一系列的名词越来越受到人们的关注。所有这些东西,其实就是为了实现一个抽象层次的编程,以保证软件的灵活性。

那什么是抽象?引用一位网友的话:“抽象就是有选择的忽略”,中国有句真理,叫“太极生两仪,两仪生四象,四象生八卦,八卦生万物”。从太极到万物,这种金字塔式的结构在复杂的软件工程中也是存在的,越接近金字塔的顶端,越要有选择的忽略掉更多的东西,从而具有更高的抽象程度。举个例子,两个功能A、B都是实现对数据的增删改,A是针对“客户”的,B是针对“产品”的,我们可以做一个增删改服务或者容器之类的东西来支持所有的增删改功能,A、B功能代码只用对使用这些服务然后再实现一些各自特殊的东西就可以了。这样做就把“增删改逻辑”给抽象了出来。再比如说O/R映射工具,它其实就是把数据操作抽象了出来。“抽象”的反义词应该是“具体”,我们可以把抽象理解为活的,具体理解为死的。各个具体的事物之间肯定会有重复,比如男人和女人都会走路,都会吃饭;比如你没有使用O/R映射工具的数据层的各个类都要实现一些相同的逻辑。软件设计中有一个原则:“Don't  Repeat”,就是不要重复。理想状态下,一个系统的任何代码、逻缉、概念在这个系统中都是唯一的,这样的系统肯定是非常灵活,因为“抽象”对应“活”。唯一性很容易保证,但是逻缉、概念的唯一性就很难保证,应该说是根本保证不了,概念这东西抽象到最上层什么都没有了。什么事情都有个度,只能说是软件的灵活性会随抽象程度的提高而提高。

这么说,是不是就意味着抽象程度越高越好?不是!刚才说了,任何事物抽象到最上层就是叫“事物”,还从哪来软件?一些书目中或明或暗地提到软件设计肯定有个最好的抽象程度,而且我们应该去努力达到这个抽象程度。不错,说得很对。但是,项目与项目之间是不同的,不存在适用于所有项目的最好抽象程度。 我的一个同事给我说过一句话:“软件项目的成功标志是什么?有三点:客户满意,公司满意,员工满意”。客户怎么满意?软件按照预算工期、成本完成,并为为他们创造价值;公司怎么满意?软件按照预算工期、成本完成,并为公司创造利益;员工怎么满意?软件按照预算工期、成本完成,开发过程顺利,自已的利益得到保证。得到的结论就是软件项目顺利的按照预算工期、成本完成,就算是成功了。运用抽象的最终目的肯定是促使项目成功,并不是让你搞“科研”。一个项目的所有因素决定了这个项目最好的抽象程度,项目经理、架构师需要反复思考,软件设计时究竟抽象到什么程度最好?这肯定要根据现有的资源(开发人员、工具等)来确定,如果过于抽象,你水平到位,可以理解,那么下面的开发人员呢?你必须要考虑培训成本、沟通成本,过于抽象,会延长工期,甚至让项目遥遥无期。

说了这么多,并没有给出一套权衡的方法,在下实在水平有限,其实在自已带领的项目中也并没有把这些东西把握得很好,希望认真思考过这个问题的人能留下你的只言片语。

posted on 2006-08-22 20:21 沈豫龙 阅读(1546) 评论(6)  编辑  收藏

评论

# re: 抽象程度思考 2006-08-22 20:36 wy

永远支持你!----王钰  回复  更多评论   

# re: 抽象程度思考 2006-08-22 20:38 杨一

设计模式是敏捷开发的工具,首先要快速的相应需求,当问题出现变化时,可以参考模式进行重构,随需而变,一些框架可以“诱导”你通过接口调用,应用策略,模版方法一类的模式,以及测试驱动开发。从而减轻应用抽象模式带来的副作用。如今的企业应用,我个人愚见,抽象起来变成了:WebSQL客户端+工作流引擎。  回复  更多评论   

# re: 抽象程度思考 2006-08-23 17:19 plexchina

非常正确!!
事实上,目前项目开发周期的延长不是因为技术上抽象的太少,而是过度。见过很多项目组以这种抽象为美,进入了误区而不知觉。是一种可怕的现象。

私自以为:
项目中业务模型抽象的太少;
技术抽象的太多。  回复  更多评论   

# re: 抽象程度思考 2006-08-24 09:45 pear

呵呵,我做项目有点感觉是在套设计模式,呵呵。真的不太理解真正的设计,懂的差不多就是套模式了。惭愧,惭愧。  回复  更多评论   

# re: 抽象程度思考 2006-08-24 16:31 stonexu

好的设计是节省工期的。当然,设计首先是要满足用户的需求。重用是为了后续项目的便利,更多是为了公司的长远利益,适当牺牲当前项目的工期,也是值得的。就看怎么取舍啦。  回复  更多评论   

# re: 抽象程度思考 2006-08-24 19:51 Rivarez

现在做的设计,拼命的抽象。。。于是,忽略了显示——工期。设计,感觉是在理想和现实中找一个合适的权衡点。所以,项目设计是不会有完美的时候。  回复  更多评论   


只有注册用户登录后才能发表评论。


网站导航:
 

导航

统计

常用链接

留言簿(2)

我参与的团队

随笔档案

搜索

积分与排名

最新评论

  • 1. re: 抽象程度思考
  • 现在做的设计,拼命的抽象。。。于是,忽略了显示——工期。设计,感觉是在理想和现实中找一个合适的权衡点。所以,项目设计是不会有完美的时候。
  • --Rivarez
  • 2. re: 抽象程度思考
  • 好的设计是节省工期的。当然,设计首先是要满足用户的需求。重用是为了后续项目的便利,更多是为了公司的长远利益,适当牺牲当前项目的工期,也是值得的。就看怎么取舍啦。
  • --stonexu
  • 3. re: 项目修复-把有麻烦的项目带向成功
  • 总结得不错,管理就是管理人心,这种项目士气是很重要得。
  • --stonexu
  • 4. re: 抽象程度思考
  • 呵呵,我做项目有点感觉是在套设计模式,呵呵。真的不太理解真正的设计,懂的差不多就是套模式了。惭愧,惭愧。
  • --pear
  • 5. re: 抽象程度思考
  • 评论内容较长,点击标题查看
  • --plexchina

阅读排行榜

评论排行榜