困惑：面向过程和面向对象的结合？

>面向过程的系统有相应快，效率高的特点
谁说面向过程快？汇编语言是最初语言，更快呢！现在双核运行以前basic更快，在这种情况下，追求性能快已经没有意义。

效率高也不对，只能说第一次迭代时开发效率高，但是随着你对系统认识深入，开发效率就越来越慢，合起来算效率高？这里反映我们的脑子思维出问题了，以为软件开发是一锤子买卖，一次开发就搞定，这反映年轻人猴急不成熟心态。软件是有生命的，是随着我们对需求的深入理解，不断进行开发维护，采取OO会越开发越快。

面向过程和OO是一对矛盾，不能并存，一旦并存，就是怪胎，系统一无是处。

另外不要觉得正在发展的思想就是不成熟，OO思维发展越迅速，说明老的面向过程思维就越应该必须抛弃，就像如今武器装备一样，现代武器发展迅速，你就以不成熟为借口，坚持使用大刀长矛做武器。
[该贴被banq于2007年02月19日 09:49修改过]
[该贴被banq于2007年02月19日 10:13修改过]

>谁说面向过程快？汇编语言是最初语言，更快呢！现在双核运行以前basic更快，在这种情况下，追求性能快已经没有意义。
banq老大，这样比较没有意义吧，我说大机的效率比pc高，这样说有意义么？？你用p4双核跟我的286进行PK这样还有什么意义？？而且老大你把软件的意义狭隘了，现在很多工业设计对时序要求十分严格，否则就会产生错误，比如医疗系统，如果一个时序出错，就会要了病人的命。

汇编语言现在就没有市场了么？？为了提高速度，我们经常做系统分析找到系统最慢的部分，然后进行改进，如果实在不行，我们真的使用汇编嵌入的方式。单独的某个方法使用汇编会影响这个的系统设计么？？

bang说得有点太极端，太绝对。
面现对象的优势大家都知道，但也不是说过程就一无是处。

借用你自己的比喻 “ 如今武器装备一样，现代武器发展迅速，你就以不成熟为借口，坚持使用大刀长矛做武器” ，现在部队装备的主要是枪炮，也主要用枪炮来作战，但匕首很多部队也装备。

就面向对象和面向过程而言，我想面向对象较面向过程改进的地方是先抽象或概念问题领域，把问题领域尽力提取出或分离成一些无耦或低耦 子问题或子领域（object？？ 包？？ ），但是要解决“领域的实际业务问题“ 还是需要根据业务需求把这些个子领域的功能组合起来。。 这个过程离不开过程。
单从这方面说面向对象是把原来赤裸裸的”过程“隐藏到不同的“objcet”里罢了。 没有过程就没有业务！

谢谢版主。我还想跟你讨论一下。
我所说的效率高是指：运行效率高，一般面向过程的系统以数据流作为处理主线，节点之间直接传数据，传输效率高，没有附加信息，实时性也好。如果采用面向对象实现，需要主动发出的数据不能直接广播或者点对点发出，需要几个步骤：1）将修改过的数据写在一个类中；2）调用需要接收数据的类的一个方法，通知其有数据修改；3）需要使用数据的类再通过拥有数据的类的方法取走数据（即：观察者模式）。这个过程来回操作步骤多，而且有多个节点需要数据时还要各个通知，各个自取，效率显然很低，传输延迟大。这在很多专用系统中是不能容忍的，不知您怎样看待这个问题。
也希望其他朋友帮我分析一下。

那么楼上的问一下
如果遇到这种情况你不使用oo的时候你怎么写代码
send(obj1,data);
send(obj2.data);
……
send(objn,data);
是不是这个样子？？
或者是obj1.recv(data)……
这个样子的

那么对象不存在那？？
你是不是还要写 if(obj!=null)

再数一下个数，如果要给N个对象写东西，那么需要的操作是N
如果用了观察者模式的notify，是不是也是N？？
多了调用了么？？

支持一下楼主。本人也认为面向过程和OO是可以结合的。类似DDD里的Model和Service。其实每个Service也是一个函数集，用起来我过程式开发中的函数类库差别是不很大。某个局部性能的优化，用到汇编，主架构是OO的，这样的应用在游戏中就常遇见到。过程式的脚本作为应用程序的后期扩展，也是一种OO和过程式的结合。

我个人一直使用并极力支持OO，但OO作为一种思想，它并不是万能的，优势劣势摆在那里。本身语言继承，多态的机制，对象的访问完整性等，都会造成性能上的不足。硬件的提升是线性的，而OO本身带来的一些性能损失是非线性的。所以也不能一味就指望硬件的提升来解决问题。面对现实的问题，灵活应用OO和过程式的特性，我想这才是真正的高手吧。

所以楼主提出的两者如何结合应用，我想应该是一个很好的话题

当然，补充一点，其实OO要写出高效的代码，除了象游戏或复杂算法偶尔需要用到汇编外，其它的性能还是可以的。只是要掌握OO，并合理设计的难度很大，对于职责的粒度把握没有明确的标准，分得过粗，就有过程式的味道，分得过细，系统变得复杂，性能就容易出问题。

过程式和OO结合的例子，还如：WebService或着dcom，我想到了远程调用这一层面，复杂的OO对象最好不要暴露给调用者。一般传递些简单的，没有层层关联过多子对象的最好。甚至不要传递对象，传些简单的值类型参数就可以了。一是因为如果复杂OO对象的传递，在代理端要生成的代码也多，一是因为作为服务给不同语言来调用，有些甚至是非OO的语言，所以这类接口最好写得类似过程式的简单函数集。

恢复COOLYU0916：
直接调用windows socket 函数，TCP/IP 广播，些一个发送命令，包含在广播组内的节点全部收到，效率高，一般延迟不超过50毫秒。

恢复COOLYU0916：
直接调用windows socket 函数，TCP/IP 广播，些一个发送命令，包含在广播组内的节点全部收到，效率高，一般延迟不超过50毫秒。

观察者模式 通常是面对同一进程空间的解决方案
你说得是网络传输方案，有一些区别的

首先广播应当是一个UDP的协议，本身就比tcp/ip速度要快
第二方面广播是一个推的概念，而不是拉的概念，接收方也不需要确认受到信息（当然你可以通过程序实现，但是协议本身不包含该功能）
第三，可以用CORBA来协助你完成这个功能

回复。与coolyu0916探讨：
第一：UDP 是TCP/IP的一种；
第二：我是希望用OO实现快速推(向所有或者部分指定节点)数据的功能，但是不知道有那些技术架构，OORBA是我考虑的产品，但是也不能实现上述功能，它是分布式对象的实现，简单说就是把远程的对象通过代理象在本地使用一样，但它还是OO，还要通过观察者模式的几个步骤才能完成数据的推，效率太低，COOL大侠，你还有那些高招，支几个。多谢！

呵呵，那我说说我的一些见解

1、udp跟tcp我认为是不同的协议。tcp有的书上称之为虚电路，也就是是一个有连接的协议，你每次connect的时候，根据协议本身就有会三次握手，如果不成功connect就失败了，发送数据包的顺序于路径完全相同，数据包的顺序是完全固定的（发的时候0在1前面，收到的时候必然0在1前面）。udp协议则不然，它只需要知道目标地址即可，对传输的路径、过程以及是否传输到并不关心。目标地址不存在都是可以的，你发送之后是否收到协议本身不关心，但让你可以要接收方发送回执来实现。这属于你给予udp写的你的协议。

2、我不知道你最终实现的语言是什么。ace是我看到的c＋＋实现的最好的网络oo设计的framework，而且可以跨平台使用。现在好像除了jace，我没有见到也没有研究过。

3、再重复一遍我上个帖子里面我说得，oo的设计模式大部分都是为了统一进程空间内的设计，既是为了一个程序使用的，两个程序之间使用设计模式不是很好的方法（甚至根本用不到，因为进程间的通讯方式就那么几种，而且效率也不是很高）。

4、从你说得中，我觉得你分层好像没有做好，首先传输层就是一个传输层的事情。比如定义一个只具备send以及recv的接口即可，使用tcp，udp，tcp短连接、长连接都由他的子类实现。然后是message接口，定义tobuffer，以及frombuffer的方法，实现与数据包之间的转化。然后在进程中使用观察者模式。比如我写过一个在局域网内的udp协议的msn message。客户端启动会给网内广播一个包，收到后，每个客户端在自己的list<user*>进行添加，然后更新人员tree，然后会有右下角的小窗口，同时发送回执，客户端根据回执生成自己的list<user*>然后再维护tree。退出时就要通知list<user*>离开，也是这样一个过程。每次发包都是user->transMessage(Imessage* msg)
[该贴被Coolyu0916于2007年03月04日 13:19修改过]

呵呵 不用争了。 你们都跑题了。Coolyu0916 好像对网络程序比较有研究，是不是原来作过c++啊。 我也是c++转过来的。

to arli :
如果你要的是一组计算机之间的通讯功能， 我知道有个jboss 的jgroups，开源免费 可以看看， 希望对你有帮助

JGroups is a toolkit for reliable multicast communication. It can be used to create groups of processes whose members can send messages to each other. JGroups enables developers to create reliable multipoint (multicast) applications where reliability is a deployment issue. JGroups also relieves the application developer from implementing this logic themselves. This saves significant development time and allows for the application to be deployed in different environments without having to change code.
[该贴被Edgra于2007年03月05日 16:32修改过]