当前页面: 开发资料首页 → Java 专题 → 再谈OO 的概念
再谈OO 的概念
摘要: 再谈OO 的概念
OO 概念非常之广，简单地说是现实世界的一种简化映射。
OO的出现是为了重用，这是OO的精华。
OO本身并没有脱出结构化编程的概念，这从OO的汇编可以看出，实际上一种语言的自我进化，描述世界仍然可以用最初级的语言，只是累点儿。
现在在讨论的应该是是否有更好的东西来描述世界，更快，更方便，相对于OO。如果存在这种东西，往往还需要OO的语言来实现，那也可以说是OO描述了这个世界。
OO可以简化为结构化＋代码生成＋动态地址，实际上在C＋＋中也是这样实现的，毕竟C++是由C来完成的。
目前比较重要的是选择一种既有的成熟方法来描述世界，然后进行大量地描述转换工作。
OO实际上引出了人们对现实世界的类型定义，这个类型是研究了实际对象后的一种总结，现实世界中只存在于实际对象，类型定义是人们后来加上去的，甚至类型定义本身也是一个实际对象（有点绕了，不过确实如此）。
但OO的问题不在于是否有足够的表现力，而在于是否太复杂了，从基本对象开始定义起到最终的系统定义，OO要描述和经历的过程实在是太复杂了，相对于图是不够简洁的。但是如果base on 库，就不一样了，这就是为什么类库会层出不穷。但是非标准的类库又带来另一个问题，歧义和兼容性问题，这就是OO带给人们的混乱和复杂。
如果想象一下，现在世界上有这么一个类库，将世界中的大部分对象已经作了描述，公开在网上，并且允许在一个标准委员会监督下进行公开修改。所有的人都使用这个类库描述，那么软件系统实际就相对简化了。比如开发一个考勤卡系统，从网上下载考勤卡相关对象，建立一下相关对象的逻辑关系，使用持久化技术存入持久化数据库，使用界面关联技术直接呈现界面，使用域逻辑技术编写域逻辑，一个软件就OK了。
所以标准化类库才这么地受人关心，因此也指出一个问题：任何一种描述世界的方法都是如此。
比如人类自然语言，我们有字典来解释每个字或词的含义，用上下文来确定具体含义。又比如UML，用例图来确定有用的事情，而含义则是借助自然语言，那么其实UML偷了一个懒，又或者是重用了一下自然语言，所以会觉得用例图是那么地贴切，实用。
DSL(Domain Specific Language)的描述也是类似，用一种领域内通用或熟用的描述语言来描述这个领域的事情，并且用转换器来转换成代码或计算机能识别的描述。DSL借助的是该领域内的通用字典，并且使用大量的自然语言约定，社会共识等等，将其规范化和标准化，使计算机可以直接使用。这可以说是一种重用也可以说是一种偷懒，毕竟重用节省了工作量。
ROR(Ruby on Rails)就很多地利用了这种约定俗成，比如缺省表名是类名的复数形式，缺省框架就拥有CRUD功能，引用类的关系定义方便等等。并没有创建什么新的东西，但连在一起就是一个全新的框架，并且实用性相当地好。
来描述一个软件系统，那么使用C也好，JAVA也好，汇编也好，都可以做到，但只有真正实现了标准类库或者说标准定义库才能使这件事情做得快而方便，可以真正地被企业所应用，被客户所接受。JAVA的成功，从某种角度来讲也是得益于其全面而标准的JDK类库。DELPHI的成功...多种例子。
UML存在这种问题，即没有提供标准UML库，这样阻碍了UML的普及和实用。UML中的重用是比较困难的，基本上拷贝贴粘，而没有实现象OO那样的重用机制，因此建立标准定义库也是艰难的，另外细节描述上也存在了大量问题。但主要的问题在于用UML描述细节实在是太累了。如果想象一下UML实现了重用和标准定义库，那么我们现在要做什么？从网上继承一下某UML库，挑几个画一下关系就完成了设计，不要太简单哦！
SQL和关系型数据库的成功就在于此，为什么这么多年还是甩不掉RDBMS？ORACLE为什么还是要出现？OODBMS已经不错了，但还是代替不了。就是因为SQL标准。一个大部分数据库都会偏差的SQL标准还统治并且将继续统治持久化存储领域很多年。想象一下假如有一种标准化OO库，公开，标准，象维基百科一样，那么OO描述的生存力将超过SQL，甚至RDBMS可能在一夜间死去，仅作为一种历史再翻出来看看。
任何一种可扩展，重用的描述基本上依赖于标准化库的建设，有优良的标准化库和成熟的应用的支撑会让这种描述走得更远。而成熟的应用也是因为优良的标准化库而产生的。
另外，还有一点，简洁也是非常重要的。UML的流行不是因为复杂，而是因为简洁，实际上这九种图相当地简洁，人们就是想追求一种简洁而信息含量大的描述方法，所以选择了UML。但是简洁与细节描述是死对头，这要借助于标准化库来作桥梁，UML现在使用部分自然语言和社会约定来作标准化库，估计以后使用DSL或其他描述来建立标准化库。
一个理想的标准化库的建议跟维基百科是很类似的，最初的库除了描述方法的定义什么都没有。任何人可以公开地修改库，当一个标准类型定义比较成熟的时候，正式进入该库，经过一段时间地积累，产生了一系列标准类型定义来指导软件系统，这时候其他的描述定义需要参照这个标准化库来转换成自己的描述定义。
象现在的JAVA，可以充分建立类库，将软件系统中需要描述的对象都建立进去。这样OO的描述基本上可以生存很多年，并且将成为事实标准。而观察现在EJB的定义都打仗这么长时间，估计这种标准类型库建起来太难了......(时候觉得SUN一家公司开发也有好处，至少不会象C++这样太多的类库，反而无用，标准化组织好象一直都只会拖后腿，民主这个东西实在太容易伤害自己了。)
Java, java, J2SE, j2se, J2EE, j2ee, J2ME, j2me, ejb, ejb3, JBOSS, jboss, spring, hibernate, jdo, struts, webwork, ajax, AJAX, mysql, MySQL, Oracle, Weblogic, Websphere, scjp, scjd
↑返回目录
前一篇: Java Thread in JVM
后一篇: Matrix Java 大讲坛－产品开发过程(Jerry贡献)