面向对象的概念是否被神化了？

cuckoo framework 中的ajaxdatagrid

<cf:ajaxdatagrid sqlKey="getUserList" header="姓名,年龄,性别,成绩" />

sqlKey指sql语句的代号，保存在xml文件中的。header是列头。

这个tag很简单的数据库中的值给查询出来了。

SQL能不能搞定业务？能！

oracle提供很多功能，如存储过程，函数等等。

我们可以利用存储过程和函数的作用，高效简单的实现业务逻辑。

如果使用目前各式各样的持久层框架，就没有这么轻松了，劈里啪啦花几个小时写一堆所谓的面向对象的代码，最终的目的还是一个，把结果查询出来，说不定查询的速度还慢的要命。

有时候感觉面向对象的概念被神化了，大师们在追捧，大拿们在鼓吹，老板们在赶时髦；其中的涉及的利益链很深，最倒霉的是程序员在疲于奔命的学习、加班。

面向对象是一种想法，不知道程序员们有多少真正了解；老板问你会不会Hibernate，会就给高点工资，于是程序员在想Hibernate是必须要学的；大家应该都明白用简单的方法做好事情的道理，可到了代码开发，偏偏追求时髦，把简单的问题复杂化。

围绕关系数据库进行各式各样的业务应用，我们是否有更简单的方法？

评论

24 楼 runthu 2008-07-16  

abo 写道

作为一个从过程语言过来又长期从事行业（零售和分销）应用的人，我与楼主有同样的感觉。前者可能使我对OO始终没有深刻理解，而后者的经验是应用的成功主要取决于对业务的深刻理解和高效地实现各种交易的处理。

感同深受，用简单的技术达到目的，何乐而不为？

23 楼 abo 2008-07-16  

作为一个从过程语言过来又长期从事行业（零售和分销）应用的人，我与楼主有同样的感觉。前者可能使我对OO始终没有深刻理解，而后者的经验是应用的成功主要取决于对业务的深刻理解和高效地实现各种交易的处理。

22 楼 Acaleph 2008-07-16  

技术一直在追求完美，这样我们才有进步。几千年之后，我们还在用锄镐来农耕，也可以达到目的。

21 楼 runthu 2008-07-15  

看来还是表达的问题，原本想表达的意思是：用简单的方法比如sql实现所需要的功能，不一定什么都需要ORM，需要OO，应该随需而定，轻松高效的开发，不要为了api而api,我们得了解好需求，做好前期设计，组件化编程，别让时髦的概念使开发迷失了方向，也体现简单才是美的真谛。

20 楼 graying 2008-07-15  

的确，标题没错，内容就说的有些偏颇了

19 楼 tibetjungle 2008-07-15  

引用

会hibernate不一定就有OO的思想，OO的思想关键在于可维护性和可复用性

是否将业务代码写进sql和复杂的存储过程是由客户需求和后期的维护性决定的
对于一个复杂的存储过程，肯定是不易维护的

复杂的sp的确太难维护了！我们公司的数据库是计算密集型的，重要的业务逻辑基本上是在sp中实现的。光是pkg就有好几十个，每个pkg中还有无数的sp或者function，看起来头就大，遇到pkg之间相互调用的情况就更让人抓狂了。

18 楼 tibetjungle 2008-07-15  

runthu 写道

cuckoo framework 中的ajaxdatagrid

<cf:ajaxdatagrid sqlKey="getUserList" header="姓名,年龄,性别,成绩" />

sqlKey指sql语句的代号，保存在xml文件中的。header是列头。

这个tag很简单的数据库中的值给查询出来了。

SQL能不能搞定业务？能！

oracle提供很多功能，如存储过程，函数等等。

我们可以利用存储过程和函数的作用，高效简单的实现业务逻辑。

如果使用目前各式各样的持久层框架，就没有这么轻松了，劈里啪啦花几个小时写一堆所谓的面向对象的代码，最终的目的还是一个，把结果查询出来，说不定查询的速度还慢的要命。

有时候感觉面向对象的概念被神化了，大师们在追捧，大拿们在鼓吹，老板们在赶时髦；其中的涉及的利益链很深，最倒霉的是程序员在疲于奔命的学习、加班。

面向对象是一种想法，不知道程序员们有多少真正了解；老板问你会不会Hibernate，会就给高点工资，于是程序员在想Hibernate是必须要学的；大家应该都明白用简单的方法做好事情的道理，可到了代码开发，偏偏追求时髦，把简单的问题复杂化。

围绕关系数据库进行各式各样的业务应用，我们是否有更简单的方法？

感觉在sp中封装业务逻辑，或者在数据库上执行计算和面向对象是两码事。你总不能直接在pl/sql中调用sp，直接看sp的输出结果吧？你总要提供界面给他输入参数，然后把参数传给sp，sp再根据参数执行。而这个过程是可以用面向对象的思想来封装的！另外，sp的执行结果还是需要其他代码、模块来展现！这个也可以用面向对象的思想来封装。当然你可以不用，用与不用的差别试一试就知道。

17 楼 runthu 2008-07-15  

哈哈，看来还要看实践来检验了。

16 楼 careprad 2008-07-15  

过度设计和敏捷开发

15 楼 nihongye 2008-07-15  

佛曰：止，止，面向对象妙难思，

14 楼 soleghost 2008-07-15  

runthu 写道

cuckoo framework 中的ajaxdatagrid

<cf:ajaxdatagrid sqlKey="getUserList" header="姓名,年龄,性别,成绩" />

sqlKey指sql语句的代号，保存在xml文件中的。header是列头。

这个tag很简单的数据库中的值给查询出来了。

SQL能不能搞定业务？能！

oracle提供很多功能，如存储过程，函数等等。

我们可以利用存储过程和函数的作用，高效简单的实现业务逻辑。

如果使用目前各式各样的持久层框架，就没有这么轻松了，劈里啪啦花几个小时写一堆所谓的面向对象的代码，最终的目的还是一个，把结果查询出来，说不定查询的速度还慢的要命。

有时候感觉面向对象的概念被神化了，大师们在追捧，大拿们在鼓吹，老板们在赶时髦；其中的涉及的利益链很深，最倒霉的是程序员在疲于奔命的学习、加班。

面向对象是一种想法，不知道程序员们有多少真正了解；老板问你会不会Hibernate，会就给高点工资，于是程序员在想Hibernate是必须要学的；大家应该都明白用简单的方法做好事情的道理，可到了代码开发，偏偏追求时髦，把简单的问题复杂化。

围绕关系数据库进行各式各样的业务应用，我们是否有更简单的方法？

会hibernate不一定就有OO的思想，OO的思想关键在于可维护性和可复用性

是否将业务代码写进sql和复杂的存储过程是由客户需求和后期的维护性决定的
对于一个复杂的存储过程，肯定是不易维护的

13 楼 flyromza 2008-07-15  

runthu 写道

个人的经验，业务上的复用，关键是设计，这里的设计不是说完全靠sql来闯天下，（也许是上面的“一个SQL引发的血案”），也不是java的面向对象的特性所能完全解决的，没有听谁说linux的C源代码就一定没有复用的特性。

其实还是前不久看到的一个争论，以数据模式为核心，还是以对象模式为核心，个人感觉在实际的开发过程中，尤其是以关系数据库为核心应用开发过程中，OO的作用似乎被神化了，是不是有更简洁简单的技术。

OO如火如荼的今天，发出这样的疑问，无疑会被骂的狗血喷头，但为什么开发效率如此低下且bug丛生，尤其是对客户需求的理解经常变动的情况下，程序员更是疲于奔命。

OO思想如果用在api设计层面，体现出来的优势很明显，简洁而优雅。但国内大部分开发者还是局限于行业应用，行业知识能否迅速有效的转化为OO思想，并提炼为干净简洁的OO代码，是个值得考量的事情。

早几年说这话还将就，现在OO已经不算是什么如火如荼了，大面积的反思已经开始了，楼主的论点没有错，可是论据却经不起推敲。

12 楼 sunny76 2008-07-15  

面向对象是看待事物的一种方式，我们也有很多其他的方法，把所有的程序做成数学公式可以不？可以。为什么不呢？因为它的可读性太差。当然这只是面向对象的一个特点，还有很多其他的就不说了

11 楼 hyhongyong 2008-07-15  

过分神化固然不对，但情况真的如此吗？想必许多都是伪OO.
面向对象只是一种思维方式，请正确的在需要使用的地方用OO！
推荐LZ看一下Martin的书：企业应用模式

10 楼 wm920 2008-07-15  

不管是怎么的技术的积累，都有一个过程，等你达到一定的量时候，就会发生质的改变，就觉的这不是唯一的方法

9 楼 nighthawk 2008-07-15  

runthu 写道

个人的经验，业务上的复用，关键是设计，这里的设计不是说完全靠sql来闯天下，（也许是上面的“一个SQL引发的血案”），也不是java的面向对象的特性所能完全解决的，没有听谁说linux的C源代码就一定没有复用的特性。

其实还是前不久看到的一个争论，以数据模式为核心，还是以对象模式为核心，个人感觉在实际的开发过程中，尤其是以关系数据库为核心应用开发过程中，OO的作用似乎被神化了，是不是有更简洁简单的技术。

OO如火如荼的今天，发出这样的疑问，无疑会被骂的狗血喷头，但为什么开发效率如此低下且bug丛生，尤其是对客户需求的理解经常变动的情况下，程序员更是疲于奔命。

OO思想如果用在api设计层面，体现出来的优势很明显，简洁而优雅。但国内大部分开发者还是局限于行业应用，行业知识能否迅速有效的转化为OO思想，并提炼为干净简洁的OO代码，是个值得考量的事情。

那是因为只打了OO的幌子，或者根本就没OO。
该检讨的是我为什么没有用好它，而不是不用它。
为什么对客户需求的理解经常变动？那是因为没有抓住问题的本质，没有分析出需求对应的领域模型。
这点，我也做的不够好，或者说是用的不够好。

8 楼 Allen 2008-07-15  

只有那些可以被越多人接受，被越多人理解，被越多人觉得好用的东西，才会有越多人来用，也才会越来越好用。

一条路很近，但是很险；另一条路很远，但是很平坦。你觉得大多数人会选择哪条呢？

7 楼 runthu 2008-07-14  

个人的经验，业务上的复用，关键是设计，这里的设计不是说完全靠sql来闯天下，（也许是上面的“一个SQL引发的血案”），也不是java的面向对象的特性所能完全解决的，没有听谁说linux的C源代码就一定没有复用的特性。

其实还是前不久看到的一个争论，以数据模式为核心，还是以对象模式为核心，个人感觉在实际的开发过程中，尤其是以关系数据库为核心应用开发过程中，OO的作用似乎被神化了，是不是有更简洁简单的技术。

OO如火如荼的今天，发出这样的疑问，无疑会被骂的狗血喷头，但为什么开发效率如此低下且bug丛生，尤其是对客户需求的理解经常变动的情况下，程序员更是疲于奔命。

OO思想如果用在api设计层面，体现出来的优势很明显，简洁而优雅。但国内大部分开发者还是局限于行业应用，行业知识能否迅速有效的转化为OO思想，并提炼为干净简洁的OO代码，是个值得考量的事情。

6 楼 eoeac 2008-07-14  

面向对象和面向过程哪个好维护？不过一样，ORM解决不了所有问题。。

5 楼 Joo 2008-07-14  

runthu 写道

哈哈，支持异见，查询只是个简单的例子，维护存储过程和维护java没有本质的区别，关键看你如何组织你的代码。

不能苟同阿
理由就不表了 sql不支持抽象类 复用都是问题