Coolyu0916 新年好，想不到过年了，你还在关心这些问题，前面我的观点主要是想表达OO的优点，针对目前国内现状，个人认为不是OO过度，而是OO不够，所以才力推倡导OO，但是具体问题具体研究，特别是性能问题依然是我们必须面对的现实技术问题，OO设计和性能实现经常是一对矛盾，需要把握平衡和适度。

最后向大家拜个年，祝大家新春愉快，全家欢乐。

oo却是是很好的东西，他能够有效的降低对事务的理解难度
而且真正的使用起oo这个工具就发现这个东西并不是一种苛刻的规则
而是对真实世界的一种真实反映
之所以现在很多时候还是以面对过程的方式来进行分析
只是因为过去这种东西的体系很完全，有着很多的经验以及方法
所以很多老手很喜欢使用他们，然后又带着他们的徒弟继续使用
没有采用oo一方面在于思维的不容易转变
还在于oo不能从一开始就给与他们好处（因为用oo进行前期分析的成本会更高，而且不容易进行测试）

效率问题我过去一直也是比较关注的，我是一个c＋＋的程序员，用c++的视角来关注这个问题，使用oo的速度成本基本在两方面，一方面是函数的成本，出入函数会有一个成本，但是可以用inline解决问题，另一个就是继承的虚函数的成本，这个对空间跟时间成本都相对比较高。但是在《设计模式》里面就说到，应当尽量少运用继承，而应该更多的运用引用复合的方式，而且继承也尽量控制在3层以下，所以这个消耗也可以在可控范围。所以oo只要不过渡应当对效率影响不大。

也祝banq大哥新春愉快。

印象里至少Robert C. Martin是极力反对用模拟现实比喻OO的，在C++风起云涌的最初几年，人们最津津乐道的就是C++的继承、多态与现实世界的随处可见的对应关系，一切都那么美好，但后来证明事实并非如此，对象系统与现实世界决非自然的对应关系，甚至是扭曲的。否则，一个需要花费巨大心血的模型根本就不需要演化得来，软件专家可以让位于领域专家了。
我的体验正如Eric在DDD中对"突破"的描述，眼看着表面上理所当然的“最接近现实”的设计如何被代码一步步割裂，七零八碎...而这个无奈的过程事实上却是迈向更深抽象的必经之路，最后，突破终于出现，一切变得明朗，经过大规模重构，软件一下子回归简单、自然，然而却更有效率、更强大...

OO确实是非常有用的思想
[该贴被saaya于2007年05月22日 06:52修改过]

To Coolyu0916
在C++中，oo的速度成本并不在你所说的2个方面。
函数调用和虚函数调用的成本都非常低。应为这些操作并不会中断CPU的流水线。
真正的成本在于大量对象的创建。
对象创建时会产生内存分配。对于大量小对象而言成本惊人。
即使使用对象池也只是略有改善。应为对象池的维护本身也是不小的开销，远远大于函数调用。
并且大量的小对象会消耗大量的内存。内存操作相对于计算来说，是相当慢的。

如果对性能很敏感的话，在实现程序时放弃OO吧。OO就是性能杀手。
建模和程序本来就是2件事，不一定要一一对应的。

In computer science, one layer increase the generosity but more or less reduce the performance. as to how much, it depends on how this layer is implemented.

I used to imagine if without Relational DB, the project has much lower risk than today.

But it seems currently, till today, the Object-Oriented DB cannot
break the monopoly. Two reasons:
1.DBA doesn't accept new technique
2.Object-oriented DB technique bottleneck
3.the rule makers in DB domain don't want to lose the RDB market. no interest to reinvest.

Hibernate is not so ideal as the bridge between OO and Relational DB.
1. long learning curve
2. performance issue ,specially in insert.
3. not so maintable

Performance is still a issue till today for some real-time software in Finance Domain. It goes without doubt the investor cannot tolerate their agent proving a "money-lost" platform due
to the performance issue.

but for the normal web application , if no big volumn requests in the same time, it should be ok.

I think everybody should be clear about the purpose of your task.
1. you belong to which layer programmer
if you are application level programmer, you should concentrate on how to deliver the application meeting the business requirment including the performance demand if there are.
Then you look for the "methodology and tools" to reach that goal in most economic way.
So OO is just a fundemental "methodology". for a big project,more things need to be considered for an architecture.
Relatively speaking, the real big project can hardly find some well known patterns to fit.
if you belong to the meta level programmer
if you are developing middleware or tools to ease the job of the application layer programmers, then the algorithm counts a lot.
Imagine: two JMS servers, why one is faster and more throughput than the other. The difference will not stand in your OO design.
Because OO design doesnt renovate sth but only organize sth in its best way.

all the current web layer frameworks are more or less same.
They dont make a innovation change in programming world.
it is not a revolution from procedure to OO.

we are human beings. Once we know a framework which can reach the goal, we are rarely willing to learn the similiar one.

EJB can realize everything in Spring but it depends on how you use it and it depends on how much time you need to reach that goal.
if it is too much, people will naturely incline to the Spring.
for example EJB can realize interceptors via dynamic proxy.
but EJB container has sth that spring can never have.
The cluster solution, which is super important for big project.

[该贴被shanghaimin于2007年05月30日 19:44修改过]
[该贴被shanghaimin于2007年05月30日 19:45修改过]

值得学习

to oxygen

如果对象创建慢了就用placement new试试，不行再加上freeList。
[该贴被tearoffhu于2009-06-15 15:25修改过]