面向对象设计的懵懂

[keven_2008]

请教一下平常做设计时不是使用传统的面向关系设计的牛人，在设计这方面我是新手。

我对一个需求的描述进行分析，抽取了用例，并对用例进行分析抽离出实体对象的属性。别的不说，从抽离出来的这些实体属性进行设计类图的时候，我有个困惑。
假设将实体类设计出来了，由于最后在表设计或其他具体实现上的原因（比如有必要的冗余），又要返回来修改这个类以满足要求。
这个过程我很郁闷，如果是过程是：
需求分析（用例）->设计类->设计表,
那可能会出现
修改表->修改类
这个过程，既然这样，为什么不直接
需求分析（用例）->抽离实体属性，设计表 -> 设计类
好吧，我承认这不是传说中的面向对象设计，但这样的过程确实要比传说中的面向对象设计舒服多了。

有牛人分享一下经验，或者提供一下这方面的资料（实际案例）参考一下，不胜感激.

[cheng20100915]

[Quote=引用楼主 keven_2008 的回复:]
请教一下平常做设计时不是使用传统的面向关系设计的牛人，在设计这方面我是新手。

我对一个需求的描述进行分析，抽取了用例，并对用例进行分析抽离出实体对象的属性。别的不说，从抽离出来的这些实体属性进行设计类图的时候，我有个困惑。
假设将实体类设计出来了，由于最后在表设计或其他具体实现上的原因（比如有必要的冗余），又要返回来修改这个类以满足要求。
这个过程我很郁闷，如果是过程是……
[/Quote]
楼主的想法是不错,我以前就是这么想的,但是它是一个既包含面向过程和面向切面的思想,这中理解方式漏洞很大,
比如先以用例来抽取实体属性,这一点要把所有需要用到的属性全部抽离出来,最终形成--表,--再形成类.
这种方式在设计数据库时效率极高,节省时间,但同样他的缺点和优点一样突出,这样设计出来的数据库表和类,如果发现少了一个什么属性,这时就要再添加一次,这种情况被人称之为拼凑设计,他对应开放小型数控库设计很适用,但对与对数据库表数量过大的项目完全不适应,
这种设计方式你可以用来做一些练手的小项目,但要给别人做项目,这种方式行不通,还有一个最大的缺点:不能进行二次开放,这在于商业竞争中的品牌升级是很难发实现的,二次开发成本甚至高于第一次开发.
楼主的想法和我当初有相似之处,不知道我的理解是否让楼主满意.

[RefreshingBreeze]

接口,多态

[keven_2008]

终于等来3楼降临。首先谢谢你的回答。
我也是觉得这种方式有违面向对象设计的原则，实际上，我还认为在关系数据库中完全用面向对象的想法来实现设计也不是一贯适用的，即使完全用面向关系的方法生成表结构，然后我们也许会在性能上对表进行优化，采用或者拆分表，或者冗余等各种手段，这个优化的过程其实不就是有悖面向对象设计原则的吗？但这样的需求有时候却是不得不做的呀。

3楼提出了这种做法的不可取，那能否在分享一下，在这种需要对表进行优化修改等的情况下，又当如何科学采用面向对象设计的方法来实现呢？

[keven_2008]

[Quote=引用 6 楼 yang4187668 的回复:]
这个又回到了先有表还是先有类的问题上了

1、先设计表，相信多数公司都这么做，为什么会这么做，比较复杂，难以说清

2、先设计类，更符合OOP的思想，而且数据库都是关系型（这个问题别和我争，没有意义）
[/Quote]
谢谢，不过你还是陈述了我的疑问，没有解答我的疑问。

[yang4187668]

源引公司以前架构师的一句话：先入为主，现在多数人还是以面向过程的思维做面向对象的事，只是把函数换成方法，变量换成属性而已，完全以面向对象的思想（不含一点过程）来做程序的基本没有。

[yang4187668]

漏了最重要的一个词，“国内”

[yang4187668]

这个又回到了先有表还是先有类的问题上了

1、先设计表，相信多数公司都这么做，为什么会这么做，比较复杂，难以说清

2、先设计类，更符合OOP的思想，而且数据库都是关系型（这个问题别和我争，没有意义）

[keven_2008]

多谢楼上的回答。但是还是心中的疑问仍然在。

我觉得完全面向对象的设计方法在实际运用中，特别是当前的数据库几乎都是关系数据库的情况下，在设计数据库的时候无法非常适用。不知各位觉得呢？

[xiaoniaoxiangfei]

面向对象最大的好处就是，易维护，易扩展，可复用，灵活性好，所以你在抽取一个用例后，应该考虑到以后会出现的某些情况，也就是向后兼容，对修改关闭，对扩展开放，所以应该先设计出类。。然后根据类的需要在去设计保存数据的表。但是由于数据库都是关系型的数据库，所以很多的时候是不能满足我们对象的需求，或是性能上的需求，我们就需要对表做一些操作，其实就是一些手段罢了。这样让我们能够尽最大的可能满足需求。而你说要修改表--》修改类，那就是前期考虑的不足。。如果考虑的很充分的话，还是遇见修改表---》修改类的话，那么只能说明是你的需求在发生着变化。需求都变了，那我们的表怎么能不变，类怎么能不变呢。

[keven_2008]

[Quote=引用 12 楼 xiaoniaoxiangfei 的回复:]
面向对象最大的好处就是，易维护，易扩展，可复用，灵活性好，所以你在抽取一个用例后，应该考虑到以后会出现的某些情况，也就是向后兼容，对修改关闭，对扩展开放，所以应该先设计出类。。然后根据类的需要在去设计保存数据的表。但是由于数据库都是关系型的数据库，所以很多的时候是不能满足我们对象的需求，或是性能上的需求，我们就需要对表做一些操作，其实就是一些手段罢了。这样让我们能够尽最大的可能满足需求。而你说要修……
[/Quote]
面向对象的设计，至少不能针对数据库性能进行设计吧？也就是也许设计出来的实体类映射成表的话，性能达不到预期，这时候就必须对表修改了。这情况怎么折衷？

[myloveyoyo1314]

个人对面向对象的理解也不是很透彻 但是面向对象的好处是代码重用和维护方便

抛开什么面向对象不说 只是把所有的逻辑都写在一个方法里也能完成需要的代码
但是维护这种代码是个灾难

先设计类 是因为类和类之间 逻辑和业务逻辑是相关的 也就是
先把业务逻辑化身成一个一个的类 类和类之间是有关联的
然后将类设计成表
这样 表和类 类和业务逻辑之间是有关联的

先设计表在设计类 类是依赖于表 而不是依赖于业务逻辑 当然 你也可以说表是从业务逻辑而来的啊
这样设计比上面那种方法简单么? 如果务逻辑变更了 你需要怎样修改你的代码 ?


即使你先设计表 在设计类 也会有修改的情况 因为一个程序开发只占它生命周期的百分之十 也许更少 很长的时间 都是在维护 维护就是这样 改改这 改改那

[liujun822]

楼主项目的一般过程分为，需求调研 --- 需求分析说明书 --- 概要设计 --- 详细设计 --- 编码 --- 测试 -- 发布。
而关于类图和数据结构图的设计我们应该放在详细设计，在相信设计阶段我们需要定义好每个功能模块所需要的类，以及类中的方法，并模块的类图，时序图，这样我们就能很清楚了每个功能模块需要的类和方法了，然后在设计数据库，以及数据库所对应的实体类，一般项目流程都是这样。

楼主需求分析（用例）->设计类->设计表 你这部中的设计类所指导是设计项目中每个功能模块我需要的action，service，dao，facade以及实现这个模块，每个类中所包含的方法。
然后我们在设计数据表的时候，在会去设计数据库表所对应的实体，以及每个实体中所包含的属性。

[keven_2008]

自己顶。。。。

[landyshouguo]

[Quote=引用 10 楼 liujun822 的回复:]

楼主项目的一般过程分为，需求调研 --- 需求分析说明书 --- 概要设计 --- 详细设计 --- 编码 --- 测试 -- 发布。
而关于类图和数据结构图的设计我们应该放在详细设计，在相信设计阶段我们需要定义好每个功能模块所需要的类，以及类中的方法，并模块的类图，时序图，这样我们就能很清楚了每个功能模块需要的类和方法了，然后在设计数据库，以及数据库所对应的实体类，一般项目流程都是这样。……
[/Quote]顶

[bastengao]

四个字，面向对象，

[luffy927]

学习学习

[keven_2008]

[Quote=引用 19 楼 bastengao 的回复:]

四个字，面向对象，
[/Quote]
看来很多人都没明白我问的是什么。
为什么这么做，面向对象，这个我知道。我的疑问是使用面向对象这种设计方法应对现在的关系数据库的设计中，用什么样的方式来解决这个过度的“不平滑”。
或许，在现有的关系数据库中，不应该太将“面向对象”强加在数据库设计阶段吧？

[keven_2008]

顶。 。

[rinoya111]

关注中