zhrb的空间

  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  20 随笔 :: 0 文章 :: 29 评论 :: 0 Trackbacks
发信人: gentboy (老流氓,老水车,老男人就是快乐的一家), 信区: Java
标  题: 填坑:oo的前世今生及后世
发信站: 水木社区 (Fri Apr 18 13:27:06 2008), 站内

摘要:需求一直在扩展,逻辑复杂度以更高的速度增加,而人的逻辑处理能力没有任何变?
。oo解决了一个stage的问题,但是类似于软件危机的问题肯定还会出现,期待新的逻辑或
者工具来解决这个问题。


N多年前,软件危机的出现基于三个事实,一个是需求迅速增长,功能要求越来越多;再者软件的复杂度并不是与软件的体积成正比的,复杂度的增长速度要远大于代码的行数的增长速度。

还有一个没有被强调的原因就是,人的能力是有限的,对于复杂的软件,没有任何一个人能掌握所有的逻辑,即使他了解所有的逻辑,也不可能同时考虑到这些逻辑。因此,人们在编写软件时,只能在有限的视野内工作,这种情况本身就决定了软件中的缺陷难以避免。

oo被认为是解决软件危机一个比较好的方法,主要原因就是oo将整个软件中的大量逻辑和数据封装起来,从而使得程序员不必关注所有的细节,而只关注与自己负责的部分有关的细节。这大大减轻了程序员的负担,从而也使软件规模得到了较大的扩大。

但是,需求仍在继续增长,而且逻辑的复杂度又以更快的速度增长。用oo编程的程序员们渐渐感觉到即使大量的逻辑被封装了,剩下的要处理的逻辑仍然足够复杂。

而且,oo也是一把双刃剑,如果封装的方法不当,同样会给别人的开发造成麻烦。而且不同的程序员往往对同一个应用有着不同的理解。这使得协作中的冲突很常见。

因此大量的针对具体应用的framework出现了,比如orm, ejb, struts等等,这些framework从某种程度上定义了某种具体应用的范式,把应用中有共性的部分拿出来,而让程序员做那些有特性的东西。这又让程序员少考虑了不少东西。

到目前为止,framework的确起了不小的作用,也出现了很多超大型的framework,能让程序员写很少的代码就能完成原来可能要18个人干半年才能完成的任务。

但是,framework也有其本身的缺陷,一个是framework往往本身就足够复杂,难以学习已经是一些大型的framework的通病。另外framework本身也有质量问题,过分依赖或者不正确的使用framework的后果同样是致命的。

framework替你做的事情越多,程序员往往就越难以使用它,但是如果他做的东西少,程序员就会喊自己做了很多重复劳动。因此这两者之间要有一个平衡。从这个角度来讲,spring做的比jboss要好。

展望将来,需求的规模还会继续增长,而逻辑的复杂度仍然会以相对于需求的复杂度的指数形式增长。但是人的脑子跟几十年前没什么区别,还是同时能处理那么多逻辑。尖锐问题肯定会出现。

但是解决问题的方法呢?单单靠语言特性恐怕已经难以再做什么。人们应当再次反思程序这个概念本身,提出新的解决方案。或许人们会开发出更为实用的framework以定义业务逻辑,更为智能化的集成开发/协作环境工具来扩展我们的大脑,或者其它...


--


   晶晶姑娘是个好姑娘


※ 修改:·gentboy 于 Apr 18 13:28:32 2008 修改本文·[FROM: 210.13.85.*]
※ 来源:·水木社区 newsmth.net·[FROM: 210.13.85.*]

posted on 2008-04-19 10:34 zhrb 阅读(231) 评论(0)  编辑  收藏

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


网站导航: