发信人: 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.*]