我不同意楼上各位的观点.

对于软件开发来说,面向过程才是人们自然的想法,而面向对象则是一种抽象.

为什么这么说呢.
大家在一个项目开始时,做的第一件事是什么?通常是Uses Case吧?Uses Case就是面向过程的.

而面向对象里最基础的就是继承了,接口也是很重要的组成部分.而这两者都是抽象的产物,实际生活中是不存在的.
举个例子,飞机和汽车可以看作交通工具的子类,玩具飞机可以看作飞机的子类.
但是玩具飞机和交通工具就没什么关系了.为什么呢?应为从飞机到交通工具的抽象是一种人为定义.而不是自然产生的.

而面向过程则是往数学上进行抽象,这是所有自然科学采用的方法.因此我们可以说面向过程的分析手段必然是正确的,合理的.但是难度非常大.应为其他学科往数学上抽象都是由顶级科学家来做的.
另外就是每个学科都有大量的问题还没有抽象到数学,有待于未来的科学家来解决,但是软件却不能等.
因此才引入了面向对象这种比较简单的抽象方法.

但是面向对象的方法并不像楼上说的那么完美,有巨大的缺点.
最主要的原因就是他不是基于科学(数学),而是基于经验的.
因此我们没有办法定量的分析一个面向对象的系统,只能定性的泛泛而谈.

举个例子,比如我要求一个系统在有30个特定输入的时候,系统消耗的内存不超过30M.对于面向对象的系统,就不可能在系统设计时确保达到这个目标.应为对于面向对象的系统,在实际系统运行前,完全没有办法计算究竟有多少个对象会产生.

希望大家能了解这两种方法的优缺点,根据实际项目的情况,正确的选择。

>>但是面向对象的方法并不像楼上说的那么完美,有巨大的缺点.
>最主要的原因就是他不是基于科学(数学),而是基于经验的.
>因此我们没有办法定量的分析一个面向对象的系统,只能定性的泛泛而谈.

哈哈,说oo不是那么完美,实际你已经有一个潜在的前提:符合数学严谨的才完美,可是我说的完美可能是艺术上的完美呢?数学和艺术可是两个平等的领域噢,而且不能厚此薄彼噢。

所以,软件是艺术和科学的结合,不能因为软件不是完全科学的,所以,使用科学标准来苛求它。这些都是科学强权主义在我们脑海里生根蒂固的原因。

所以,OO思维为什么那么有很多人不能很好掌握,因为他们已经被培养成数理化机器了。

OO系统是不能定量的, OO设计原理没有象数学那样的定理,这些都是正常的,但是OO是符合逻辑的,甚至取决于经验丰富人的直观感觉,科学永远替代不了人类中由于经验丰富而产生的直觉,这种创造性的直觉在管理领域、经济活动、股票、政治、军事等都无法用定量数学来获得,这些都是人类的灵魂。

所以,我不是反科学,反数学,但是也不能科学数学强权,只要我们认识到这点就可以。所以,对于初学者,哲学很重要,这样就不至于陷入某个具体学科钻牛角尖了。

[该贴被banq于2007年06月08日 11:03修改过]

软件是众多工程中的一种。和建筑工程,机械工程一样。
其中可能会融入一些艺术的成分,但是本质上是科学。这是谁也无法否认的。

在工程上,我们会大量运用经验方法,经验数据。但是历史告诉我们,只有走科学的道路,才能长盛不衰。
中国古代技术那么先进,为什么到了近代就不行了?不就是应为没有突破经验的范畴,上升到科学的高度吗?

推动生产力发展的是科学,不是艺术。软件是工程,和艺术撤不上关系。

面对一个具体的工程,一个经验丰富的工程师远比一个科学家有用。
但是并不能因此就鄙视科学家,甚至宣扬科学无用论。

如果把软件排出到自然科学之外,归类于人文艺术类。那我也无话可说了。
艺术是不需要逻辑的。

大家也不需要继续讨论了。因为艺术是无法解释的。

而管理,经济,政治,军事都依靠直觉的话,这样的企业/国家也太可怕了。

哪来的那么复杂,偶粗人说说oo

oo嘛就是oo啦,你们说那么一大堆干嘛
实际项目中,把业务功能分一下,每种功能一个类,或者多个类,单个类包含的功能尽量少,然后多用点设计模式,遵循一些好的编程方式,类之间功能的互相调用么就用ioc来实现,可能有时候调用某类的时候,之前或之后需要调用其他某类来做一些工作,就可以用上aop了.
struts+spring+hibernate.再加点对象池,数据库连接池,cache.一个系统就ok了嘛.
再高级点嘛就ejb了,不会.
- - (楼下的拿臭鸡蛋砸我吧,虚心学习)

我在这里再明确一下我的观点。

我并不是反对OOP,OOP是一个好方法,这个已经有很多帖子作了说明了。而是希望大家不要盲目的使用OOP。OOP有它本身所固有的一些问题,并不是所有的场合都能运用的。

另外就是面向过程也是一种非常好的方法,并且非常成熟。在实际开发中可以说是必不可少的。希望大家不要偏废。

可以说几乎所有成功的软件都不是完全OOP的。一部分是面向对象和面向过程相结合,一部分是完全面向过程的。
完全面向对象的成功软件屈指可数。

而高性能计算更是和OOP没什么关系。基本上是面向过程的天下。

还有除了面向对象和面向过程之外还有基于对象和范型编程等其他手法。这个世界是多样性的。每种手法都有优点和缺点。

所以说要从具体应用的环境和目标出发,选择正确的手法。


面向对象的程序在健壮性和可靠性方面有重大缺陷。高可靠性及要求稳定输出的场合不适合使用完全OOP。
[该贴被oxygen于2007年06月11日 12:54修改过]

楼上的,你的意思我不是很明白。
OOP不就是封装,继承,多态么,只是编程的技巧。
面向过程和基于对象的语言,都可以以OOP的方式来编程(只要你所做的封装足够精巧,虽然语言底层并没有提供这些特性)
OOP指的是程序设计方面的技巧,具体实现的CODING跟其他语言并没有什么区别。
任何方面都是相对性的,过分的注重灵活性,带来的必定是程序性能的下降。

而高性能的计算与OOP无关,是面向过程的天下,我也不赞同。应该是编译型语言性能比解释型语言要优秀。你拿C++分别以面向过程和面向对象的方式来设计一个系统,我就不信OOP方式的性能开销是人家的几倍.

至于做软件要从具体应用的环境和目标出发,选择正确的手法 确实是事实
[该贴被gougou3250于2007年06月11日 17:12修改过]

to gougou3250
你说的很对,OOP和具体的语言无关,C也能OOP的。

但是我们说的OOP最主要的是一种建模方式。而不是编成技巧。

OOP的问题前面已经说过的,OOP的系统中,各个对象最后形成了一个网状的结构。
导致了无法评估一个操作的时间复杂度和空间复杂度。

对于一个无法评估的系统,又怎么能做到高性能呢?
真正要求高性能的软件,要求在提案阶段就确保方案能够达到要求。
面向对象的系统无法预先评估,只能采用开发完成后再优化的方式。最终优化的结果也是不可预知的。因此如果性能要求,或者是空间要求是一个核心需求的话,,OOP的方案是不可接受的。
没有投资商会来赌你最后一定能满足需求。

[该贴被oxygen于2007年06月11日 17:54修改过]

>你拿C++分别以面向过程和面向对象的方式来设计一个系统,我就不信OOP方式的性能开销是人家的几倍.

根据我的经验,如果用C++开发的话,一个完全面向对象的系统和一个完全从性能考虑的面向过程的系统,如果差距在10倍以内的话,那就已经令人惊讶了。

面向对象的系统,要求数据按照逻辑关系组织在一起,这就造成了数据存储密度非常低了。(一个30K steps的系统有300个类是很常见的。面向过程的话,struct数不会超过100的)。
由于继承的原因,插入了vptr使得数据密度进一步降低。这会严重影响CPU Cache的效果,而且增加总线的负担。

而面向过程的程序可以按照alignment和函数操作的特征进行排列,提高Cache命中率。

多态和inline矛盾。

由于多态的需要,使得heap分配大大增加。

由于封装的原因,导致大量额外的数据复制操作。

仿函数的速度大概比回调函数慢3倍。使用Bind的话,慢10倍以上。

而完全面向对象的C++程序很容易产生隐性的对象复制(参数,返回值)。

有这么多不利因素,完全面向对象系统又怎么快的起来呢?

不觉得有你说的那么夸张
>要求数据按照逻辑关系组织在一起,这就造成了数据存储密度非常低
struts不按照逻辑关系划分的?
而且函数调用链过长的话,对系统性能影响也是很大的
至于你说的,对函数方法调用的CACHE命中率,我就不懂了。
>由于封装的原因,导致大量额外的数据复制操作
这个我就不明白了,难道你的面向过程语言不需要封装?BEAN也就比STRUTS创建的时候多消耗点内存,毕竟人家有一堆GET/SET方法嘛。不同层间使用共同的BEAN,而不额外创建,就不需要大量的复制了,而且可以使用对象池,CACHE等等。
至于BIND那些用反射实现的方式,本来就不应该滥用

to gougou3250

你把目光局限在基于WEB的企业开发里面了。
在这个领域,基本上没有强制性的性能要求和空间要求。
因此我前面说的这些在这个领域是不适用。

通常的企业应用最重要的是柔性和开发效率,而且系统复杂性相当高。OOP是最佳选择。alignment,Cache命中率,总线利用率,等根本不需要考虑。

但是在移动设备,嵌入式,高性能计算等领域,性能和空间就成为核心要求了。可扩展性,可维护性,开发效率等都排在后面。

还有,我前面的比较之适用于C++,并不适用于JAVA。就性能而言Java这样的只能从算法上想想办法,不可能达到很高的水准。

面向过程的程序,整体结构就和面向对象的完全不同。struct的设计方法和Class完全不同。你去看看OS的源代码就知道了。通常是以算法为中心,或者是以数据为中心。数据的组织也是针对算法的,把一大堆DATA放在一起。(和面向对象的逻辑完全没关系。)为了节省空间,大量使用BIT(把一个int拆成2-3个部分,代表完全不相干的含义),union等手法。

a.setMember(x);和a.member = x;比就是多了一次复制啊。

而面向过程的函数调用链要比面向对象的短的多。面向对象系统中有大量的委托。另外面向过程中的小函数调用可以使用inline优化。
[该贴被oxygen于2007年06月12日 10:35修改过]

- -!
你的性能,空间不是指WEB开发啊,那没什么好说的嘛。(我以为你是说WEB开发中一些注重性能的系统,空间直接无视)
嵌入式与WEB开发是不同的东西,而且现在WEB开发很热门,相信不久的将来,很多的OS应用程序都可以被WEB服务所替代,就象GOOGLE做的很多用JS拼起来的EXCEL/WORD之类,虽然目前不是很成熟。随着硬件的发展,嵌入式对性能方面的依赖将越来越低。
请问你是做WEB开发的么
我不晓得你不断的声明嵌入式方面的性能空间重要性有什么意义,两者是不同的领域,术业有专攻,相信在这个论坛的大多数人都是专注于WEB开发的。很多你讲的东西都是没有意义的。
》a.setMember(x);和a.member = x;比就是多了一次复制啊。
这个我不是很明白,两者x都是在内存中创建的一个对象,A。MEMBER=X并没有少创建一个对象,是一个直接调用指针赋值的过程,而A。SETMEMBER(X)多了一次函数的调用,他的内部实现很可能就是A。MEMBER=X

看过你的一些文章,特别是哪个FLYWEIGHT,赞成你的观点,能给个联系方式么

Web开发毕竟只是软件业中的一小块。
这里是讨论面向对象和设计模式的嘛,当然不应该局限在web开发里。
特别是学生朋友们,谁又能知道今后会做什么呢。

web应用中空间的问题比性能严重多了。tomcat很容易应为内存问题而不稳定。不过目前也没什么好办法。顺便说一句面向过程的apache则要好多了。

我工作到现在大部分时间是从事EDA软件(集成电路设计软件)开发的。不是设计板子的,而是设计CPU这样的芯片的软件。因此对性能及内存的使用根关注一些。
嵌入式也做过一些。还有视频方面的软件。

目前在做基于Web的项目,一个数字图书馆的项目。上层是J2EE的。但是核心部分不是(核心是面向过程的)。设计系统容量是数百T。

嵌入式我比较有发言权,我自己做过些,我有很多朋友专门做这个。在很长一段时间内,硬件资源还将非常短缺。嵌入式主要有工控(包括车载设备等)和移动设备(手机,PDA)两部分组成。

工控领域硬件成本是最主要的,软件成本很低。一个产品生产几万个,几十万个。软件成本摊下来没多少的。很多地方都在用几块钱的芯片。能提高软件性能的话,就能最大程度降低硬件成本。

移动设备的话,主要问题在电池。更高的性能和更少的内存意味着更长的续航时间。柔性什么的反而不重要。如果电池技术没有突破性进展的话,也不会有大改善。

我的MAIL是Oxygen.Jian.Wang@gmail.com 欢迎和我交流。

能给我讲讲你的项目么?核心部分是面向过程的是什么意思呢?
通常的WEB程序,分前台,业务层,持久层,你的核心是指业务层的逻辑很复杂,使用面向过程的设计方式来实现么?至于系统容量几百T,那个主要是对服务器的要求比较高吧,类似于IPTV(采用刀片服务器)
我刚做JAVA半年的样子,菜的一比,呵呵 得跟你多学习学习

数字图书馆的核心价值不是业务,而是数据。确保数据的完整有效。

整个内核是一个叫做保存系的独立系统,负责数据的存储,备份和查询(只有最基本的查询功能,即给出一个Package的ID,返回该Package)。
由于数据量过于巨大,整个保存系并不是关系型数据库,而是一个定制的分布式数据库。由IBM负责开发,细节我也不是很清楚。但是和OOP没什么关系,借口也是函数型的。其实商业DB的内核都是面向过程的,接口也都是函数型的。

然后我们在保存系上面开发业务系。这部分就和普通的业务系统差不多了。

其实在实际工作中,企业应用完全OOP的也很少,主要是能力问题。要设计出一套富有弹性的业务模型,没有10年以上的开发经验根本不可能。而国内又有几个10以上经验的开发者呢?不如按照数据库为核心的做法,只要足够的人手,管理跟上就OK了。2年工作经验以内的开发人员单价还是很低的。这样的话,才能确保成本和最终的品质。

实际的商业项目和OpenSource项目着眼点完全不同。
最重要的是交货时间,品质,成本,风险。

而可维护性和扩展性通常无所谓,应为维护和机能追加是从新签订契约的。商业利益才是最终目标。

相反,做软件产品的话,可维护性和扩展性则非常重要。应为本身开发周期就比较长,维护也没有额外的收入。使用的周期也比较长。
就拿EDA软件来说,开发周期要10年以上,使用周期达到20年。远远超过企业系统了。
[该贴被oxygen于2007年06月12日 23:29修改过]