喷下面向对象的无能之处

中山野鬼 发布于 2013/08/10 00:08
阅读 1K+
收藏 3

这里不是说面向对象无能,而是面向对象对某一类问题无能。而这类问题的面很宽,甚至超过桌面的设计。这就是面向数据的问题。先不说概念的东西。

大家先想一想,自己的工作。在做业务系统时,除了对ui,就是界面的设计以及界面事件的响应等设计外,是否有更多的时间是写sql,以及维护数据库。即便你不维护,后台也有代码在维护。

大家再想想,如果你尝试用面向对象的设计思想,去处理那些实际由数据库完成的计算,会是怎么样?数据库的操作包括两大类,基础计算类,增删查改,无论你加多少条件,都是查的过程。还有一类是组织类,同步,关联、分布、回滚。 后面4个对应的是数据变化(包括迁移的)时序问题、数据的静态逻辑关系,数据的存储逻辑关系,数据的存在性问题(简单独立的回滚不复杂,带关联逻辑和同步时序要求的就复杂了)。

实际业务中,往往是对一批数据存在不同的操作行为,典型的就是不同条件的查询和统计工作。这类需求的一个共同特征是针对一批平铺的数据,进行带有不同主观的识别,本质是个信息化的过程。例如,男人有多少,女人有多少,今天卖了多少,昨天买了多少。如果这批数据完全是今天卖了多少,你对这个整体,已经没有查询的必要了。

面向对象是一个信息处理的过程(不是信息化处理)。它不单单看到的是数据,而是有机数据及其上的行为。对数据和行为进行了绑定。优点我就不多说了,缺点就很明显,面向数据的处理时,不同的行为会产生不同的信息,而重点是对数据的信息化,这个信息化是动态的,同时它只是个行为,采用类的方式进行描述,纯粹叫做没事找事。其更适合加工管道的设计模式,也即只提供计算操作,不提供计算的对象--数据,可以对任意数据进行相同的计算。这是传统过程化函数化的设计工作。sql语句,在解析后,无非形成了一个较为复杂的数据计算流程,但该流程仍然是纯粹的计算描述,经过每个计算的数据,并不会停留在这个方法的区域,和这些方法组合成一个类。因为数据是有时效性的。这个和诸如一个窗口,包含坐标数据,包含窗口移动行为是不同的,坐标数据是这类对象始终拥有的组成。

所以面向对象语言,安心组作框架,做作壳子,做作界面即可,而业务需求中,更多的是在理解业务流程并通过数据库系统进行实现调用,最终进入展示系统,展示系统的设计,是面向对象最有优势的地方,所以大多数业务系统用面向对象语言开发还有一定优势。

确实有些非桌面系统,使用c++开发。这是因为,系统结构中,有些模块具备特定类型,自身数据+特定功能,使用类的实现并无不妥。不过不采用面向对象,使用模块化设计,也一样可以完成,甚至你可以理解,一个模块就是个大大的类。但区别正常人眼中的类,这些模块类,属于系统结构的组成,简单说它是由系统自身控制,而不是由用户控制,桌面系统的类对应的对象,是由客户控制,一个类,可以动态响应客户的需求,形成多个不同的对象。同时模块所对应的类,类与类是依赖关联,而不是继承关联。如果是继承关联,就不符合程序设计中,代码复用这个基础要求了。如果不信,你可以看看非桌面系统的功能型系统,其代码中,类的继承是否很深,反之模版的设计思想被广泛使用。这不单单是效率问题,而是系统结构简化的问题。同样目标下,系统结构越复杂,系统的稳定性越差。

最后补充下什么是面向数据,记得这边有个小朋友说,程序设计只听过面向过程和面向对象,面向数据没听过。

哈没听过正常,90年代也不过才有信息资源的理论出来,现在有批国际专家在研究数据方面的理论。也即数据本身的特性。而实际上这些理论中松散的理论在数据库的设计中早以应用到实际。面向数据的设计,是围绕数据本身的设计。数据是客观 存在的东西。它要考虑的包括几个方面

1、数据的生命周期

2、数据的完整性(和关系型数据并不太一致,但很多基于关系型数据库的设计正是在做数据完整性的事情)

3、数据的一致性 (相对完整性属于静态逻辑,这属于时序逻辑,例如数据的迁移,分布,缓冲中的等等问题)

4、数据的组织格式(这个是针对数据存储和数据提取的,不属于数据本身,但很数据利用有很大关系)

第四个问题,绝大多数的应用需求开发的程序员可能碰不到。主要是系统架构设计时需要考虑,主要解决两个问题,信息孤岛的破解,和数据访问权限等安全性管理,当然他们都包括元数据的设计和组织管理问题。

这里要补充说一下,各种名称的数据总线,如osc前段时间的技术交流内容,esb等,只能说是工具,并不能彻底解决数据组织格式问题。这如同给你任何一个编程语言,并不能让你直接拥有软件一样,中间大量的工作在于利用工具特性,进行实际的设计。如果esb能有效的面向数据,进行功能开发或数据组织分析,那么是有效的,如果只是做个数据搬运,那么并不会对信息孤岛破解带来任何帮助。

如果你发现,你的数据库采用了什么分表方式,重新组织了数据库的表项关联,重新整理了查询语句,结果性能就提高了,那么你实际上就是在面向数据的处理问题。而且你会发现,这些事情,面向对象的设计思想(不谈c++,java等工具了),更本无能为力。

这里主要是给两类人说的,一类是经常在做面向数据的业务工作,但并没意识到,你的工作中,后面藏着很多理论,另一类是,现在已经或高举钞票奔向培训学校学习c# ,JAVA之类的小朋友说的。如果你认为你会了一门语言(工具)的应用,就可以安生就业了,我需要告诉你,那么就是个青春饭,在你的用工成本提升中,你会逐步被各种理由淘汰,程序设计,不单单是工具应用的问题,还包括思想的学习。基础知识很重要。不谈现在大学老师的水平怎么样,但很多课程的安排是有道理的。流行的东西,大多数是来也匆匆去也匆匆的东西,有些老东西还在,实际上证明了其强大的生命力。


加载中
1
翟志军
翟志军

首先,我很喜欢和老鬼聊。我也很赞成面向对象的思想不是银弹!

然后,我有些疑问提出:


大家先想一想,自己的工作。在做业务系统时,除了对ui,就是界面的设计以及界面事件的响应等设计外,是否有更多的时间是写sql,以及维护数据库。即便你不维护,后台也有代码在维护。
关于“更多的时间是写sql”这点,我面试过的,在网上聊的,都是更多的时间是写sql。但,说实话,我们公司倒是很少写sql。


其实,“更多的时间是写sql”,我是不是可以理解为将业务放在sql里了?这样做本身不是问题吗?


大家再想想,如果你尝试用面向对象的设计思想,去处理那些实际由数据库完成的计算,会是怎么样?数据库的操作包括两大类,基础计算类,增删查改,无论你加多少条件,都是查的过程。还有一类是组织类,同步,关联、分布、回滚。 后面4个对应的是数据变化(包括迁移的)时序问题、数据的静态逻辑关系,数据的存储逻辑关系,数据的存在性问题(简单独立的回滚不复杂,带关联逻辑和同步时序要求的就复杂了)。
你说的数据库完成的计算,我实际的工作中已经将这一职责分到了ORM持久化框架去了。我的业务对象(或叫充血模型,或叫实体),如员工,他只需调用自身的“更新我的基本信息”。剩下的持久化的事情,就是持久化框架的事情了。我的意思,面向对象的思想更多是让问题能分而治之,并且减小 人与机器之间鸿沟。没有要人们真正完全忘记自己的程序最终操作的还是数据。只不过,是将操作数据这一职责交给了生产线上的其他人。用面向对象思想设计出来的框架同样可以操作数据。



面向对象是一个信息处理的过程(不是信息化处理)。它不单单看到的是数据,而是有机数据及其上的行为。对数据和行为进行了绑定。优点我就不多说了,缺点就很明显,面向数据的处理时,不同的行为会产生不同的信息,而重点是对数据的信息化,这个信息化是动态的,同时它只是个行为,采用类的方式进行描述,纯粹叫做没事找事。
这段话不是很理解。


所以面向对象语言,安心组作框架,做作壳子,做作界面即可,而业务需求中,更多的是在理解业务流程并通过数据库系统进行实现调用,最终进入展示系统,展示系统的设计,是面向对象最有优势的地方,所以大多数业务系统用面向对象语言开发还有一定优势。
这段话,我是否可以理解为你是站在“业务是写在Sql上”这个前提下的?

如果你发现,你的数据库采用了什么分表方式,重新组织了数据库的表项关联,重新整理了查询语句,结果性能就提高了,那么你实际上就是在面向数据的处理问题。而且你会发现,这些事情,面向对象的设计思想(不谈c++,java等工具了),更本无能为力。
老鬼,这样跟你说吧。如何数据库如何设计,那是具体的技术问题了,与业务无关!那与面向对象的设计思想无关!面向对象的设计思想是为了让你的设计能与实际的业务需求更相符!


这里主要是给两类人说的,一类是经常在做面向数据的业务工作,但并没意识到,你的工作中,后面藏着很多理论,另一类是,现在已经或高举钞票奔向培训学校学习c# ,JAVA之类的小朋友说的。如果你认为你会了一门语言(工具)的应用,就可以安生就业了,我需要告诉你,那么就是个青春饭,在你的用工成本提升中,你会逐步被各种理由淘汰,程序设计,不单单是工具应用的问题,还包括思想的学习。基础知识很重要。不谈现在大学老师的水平怎么样,但很多课程的安排是有道理的。流行的东西,大多数是来也匆匆去也匆匆的东西,有些老东西还在,实际上证明了其强大的生命力。

我认同有些老东西还在,实际上证明了其强大的生命力。因为经得起时间考验的东西,才是是有生命力的东西。

我也知道,技术毕竟是技术。



1
mallon
mallon
且不讨论语言重要还是数据重要。单论语言:面向过程、面向对象、函数式三大要素齐备才能称得上是完整的语言。
0
崔钢
崔钢

面向对象其实是一个很好的技术,我觉得关键的问题在于静态类型。静态类型虽然表面上安全(编译器检查)但其实会把程序处理的数据搞的很复杂。处理数据关键的问题是对数据的抽象。其实,这个抽象并不高深,比如数组就是一个很好的数据抽象。其实我们常用的数据就两种map和list。而对数据的操作无非就是过滤和转换。最好还有闭包和宏,可以简化调用,抽象数据的处理。所以我觉得大家有必要去学习一下函数式编程。目前nodejs比较火,js在这个方面其实也是很强的。

面向对象,会搞出很多的类型出来。这个大家都是清楚的,我随便定义一个对象,就是一个新的类型。这对数据处理来说其实就是一个灾难。类型多了,关系必然复杂。描述一个层次关系,如同树,就十分的复杂。灵活的处理数据还是LISP强大。或者其他FP语言,最好有自己的抽象数据的,比如js的json,lisp的list和map。

面向对象在我看来,唯一的优点在于约束性好,适合大规模枯燥系统的开发,几个精英写抽象父类和接口,一群普通人写子类实现,照猫画虎,脑力劳动变体力劳动。这种优点可以显著的降低软件的成本。各大公司(特别是没有技术的)的最爱。

0
ueharaai
ueharaai
数据流是计算机处理的本质,看不到这个的只能是在那里搞类层次,搞接口,搞设计模式,瞎搞一气……老师教学生,应该教他们看清本质,然后用最简单最直接的方式解决问题,而不是在那里搞 那里搞类层次,搞接口,搞设计模式……大部分的学校只教学生语法,不教思想,能从学校里学出来的人,其实很牛叉。
0
中山野鬼
中山野鬼

引用来自“ueharaai”的答案

数据流是计算机处理的本质,看不到这个的只能是在那里搞类层次,搞接口,搞设计模式,瞎搞一气……老师教学生,应该教他们看清本质,然后用最简单最直接的方式解决问题,而不是在那里搞 那里搞类层次,搞接口,搞设计模式……大部分的学校只教学生语法,不教思想,能从学校里学出来的人,其实很牛叉。
数据流本身倒还好折腾。数据理论研究,目前叫数据治理。比较难的是元数据组织方面。目前的研究方向是抽象再抽象,然后标准再标准。基本都是标准化的工作。这样做的好处是,各种业务系统存在对接的可能性。不过这些属于理论部分。工程部分更多在于有效性实现上。
0
马瑞wwwwww
马瑞wwwwww
鬼哥真是人才啊
0
虚无道长
虚无道长
为啥我总感觉c完全可以也做到面向对象呢?
0
纠结名字
求以相同篇幅列举面向过程的无能之处!不喜欢就是不喜欢,废话那么多干什么?
0
中山野鬼
中山野鬼

@翟志军 哈,你们的处理,如果我没猜错,是否将数据进行流程化处理,在每个处理结点,进行对象化操作?这种思想我的理解应该是管道的思想。数据是在各个处理环节流动的。如果整个处理流程已经相对静态稳定后,那么这种流程处理的方式是种必然选择。当然这和面向对象也没有关系了。面向对象的数据不是流动的数据。是一个对象自身的属性,它是对象本身天然的组成部分。对数据的分层或分级操作,本身也是面向数据的。你的不同对象,抽象出来,应该是有生命周期的。数据的生命周期和数据的操作行为,是完全相同的,这是面向对象的一个基本特征,数据生命周期和操作行为不同,那么还是要关注数据的问题。操作行为会不依赖数据而独立设计。

至于sql,哈,其实这个举例并不完整,但说其他,怕很多人不了解。由此对应数据的处理。

0
中山野鬼
中山野鬼

引用来自“纠结名字”的答案

求以相同篇幅列举面向过程的无能之处!不喜欢就是不喜欢,废话那么多干什么?
你写吧。哈。
返回顶部
顶部