关于OOA、OOD的思考

看了数据建模 vs 对象建模 (从Ofbiz帖子切分出来的) 的帖子,使我受益匪浅，对我这种菜鸟来说，知道了什么是对象建模，什么是数据建模。文中提到的软件设计的方法也让我有耳目一新的感觉。但是里面涉及到的关于数据建模 与 对象建模那个更好的讨论，是否都站在一个统一的观点下，也就是通过对象建模方法实现的系统能适应需求的变化，使程序各层之间有低的耦合性，但我想明白的是这一观点是怎么得出来的？               
    从一个很现实的简单的例子出发，当业务需要增加一属性时，传统数据+过程的修改程序的方式是，在更新，创建此记录时，在sql语句中加入此属性，在用到此属性的业务中在sql语句中增加此属性。而对于面向对象的方法（以hibernate实现为例）是在此对象中增加此属性，并在hbm.xml中增加此属性。从修改的工作量来说并没有多大的差别。从另一角度来说，不管用那种方式，都不能对降低各层之间耦合性，因为针对具体的业务来说，需求的变化都是涉及到各层的，如增加一属性，要在web层向用户体现出来，在业务层逻辑上要体现，数据层数据访问要体现，最终的表结构要体现，这对采用什么对象建模和数据建模都是一样的。对一些复杂的需求业务的改变，对传统的方式无非是改变sql操作数据库的语句，而对象方式也就是改变对持续化对象的方式，这也没有多大的变化。是我的想法太狭义了？
    从我对观点来看，对象分析，对象建模的方法好处在于对需求的分析可能更准确一些。不知道我说道对不对？
    现在很多软件公司宣称OOA、OOD、OOP，是否OO就是一切，但OO的精髓到底是什么了？相关传统的方式，面向对象的XX对系统的实现在那个方面有所提升了？

OO的核心是分类。这样的分类是建立在其内在的相似性上。实践中不管你使用什么方法，在修改了对象的属性的时候，都会带来数据库结构的修改，除非你使用某些方法才可以解决。但是这样的方法会带来很大的系统开销和设置等的不方便。比如我在普通的关系数据库中曾经实现过相当好的对象存储，但是效能很受影响，而还要写一个专门的管理模块。所以这样的方式是不是真的低成本还很难说。而实际上很多人不太了解数据库的设计，往往认为那些范式是不能动的金科玉律。而当我们实际考察很多商业软件的数据库结构的时候会发现，那些表格和字段往往似乎和商业逻辑没有关系。当然这样做的目的还是在于为程序开发服务，而实际上商业的逻辑已经成为了一种高度抽象的元素。而究竟OO是不是一切，答案当然不是，但是这并不能说别的什么东西可以代替OO的核心地位。
而面向对象的方法最重要的是把对象作了包装，使对于局部的修改有可能不去影响其他的部分。而这些修改在实际应用中主要使对象方法的实现的修改和对属性数值的修改，而很少会发生对于属性的增加和减少。而即使发生增加和减少，那些对原来属性的调用也往往不会受到影响。

因为现在使用的数据库大部分是关系型数据库，以后发展成为OO DB，就可以把整个对象存入/取出数据库，就不会涉及到修改所有层次程序的问题了。

谢谢

我觉得这跟个人经历有关。
如果你一直开发mis，erp之类的应用，那么就会很习惯数据建模。
如果一直是开发.....比如tomcat这样的jsp container，可能大多数人都是对象建模的。
scot ambler同志说，不要追求绝对的黑、绝对的白，找一个灰色的地带，呵呵
初来贵论坛，班门弄斧一下，欢迎板砖

欢迎notty来这里，看来老家伙们要汇集与此了。

我实在不解楼上的帖子，楼上的各位好像都把对象建模和对象分析、对象设计、对象编程（也就是OOA、OOD、OOP）等同起来。
   数据建模也可以用OOA和OOD的方式，只要数据存储实体是支持面向对象的。
   我觉得各位在概念上有非常，怎么说呢，很错误的一个误区。对象建模是和业务建模，数据建模在软件研发过程中对不同内容不同范畴的一种体现，当然了，对象建模是在OO之后才有的。
    我们所有的系统，尤其是应用系统，都来自于业务建模，过去是面向过程的建模，现在是面向对象的建模，将来就是面向方面的建模，这些只是方式罢了。在以面向对象的语言体系中，要将业务建模后的模型转换了一种语言级的对象（而不是抽象的对象概念），这个我们就叫做对象建模，简单地将，就是设计类和接口。而数据建模是业务建模后的模型在实际物理存储中的一种表现，简单地将，就是设计表和视图。三者之间是相关联的，但是，也不是强耦合的。比如讲，在一个对象中有某个属性，但在一个表中或许没有（或许它是通过其他关联过来的，或许是通过某种逻辑运算出来的）。
    我实在不知道是哪位仁兄最早将数据建模和对象建模变成了一中思考的两种方式，这样，实在是误人之弟啊～～～～～～

如果要说一种思考的不同方式，就目前来说（应该是我知识不够），好像就三种：面向过程的建模、面向对象的建模、面向方面的建模，也许还有其他，但是绝对不是对象建模和数据建模之类的比较。

我觉得好象说得不是用什么方式来进行数据建模,而是从哪个角度来对系统建模.
如果是在使用面向对象数据库的情况下用OOA和OOD的方式对系统进行建模,那就是对象建模,因为你没有站在数据的角度上去分析系统,或者说没有把整个系统看做一堆数据,而是看做一些对象在交互.

  
我不认为对象建模是和业务建模，数据建模在软件研发过程中对不同内容不同范畴的一种体现.我觉得它们是对相同业务规则的不同角度的观察和体现.
    抱歉，发现我跟你讲得好象不是一件事(后面的文字太长,不引用了).我所说的数据建模是从数据及数据之间的关联和依赖的角度去分析业务并为业务建模,而不是建表结构和视图,我说的数据建模的产物不一定是个e-r图或schema.
      事实上,从我个人经验来看,对同一需求,从这两种不同的是视角来分析,确实会导致比较大的差异,当然这也许是由于我没有把两种方式都精通掌握,融会贯通,也许真正的高手是可以融合为一,做出一个完美的设计?
      两种方式都有其优缺点,虽然我自己倾向于对象建模,可以做出比较灵活的设计,容易扩展.
      但觉得数据建模也有好的地方,毕竟很多时候,数据会比软件系统活得还长久.

对象建模和数据建模真的是不同范畴的吗？其实它们只是反映了问题的两个方面，一个是反映了概念的职责，一个是反映了概念的属性，两者缺少任何一个方面都不完整。而且不管你是不是使用对象，你的数据必须还是以实体来组织。AOP绝对还谈不上可以单独拿出来成为一个体系，它只是对象的一个扩展。