在分析阶段中的实体类，到了设计阶段会衍生出多个类。如下面这样: ( 积分: 15 )

一

一

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2005-01-15

• #1

在分析阶段中的实体类，到了设计阶段会衍生出多个类。假设这个实体类叫做order，那么设计阶段应该具有这样几个类：OrdebBLL，这个类用于实现order的业务逻辑，它包含分析模型中相应类的职责；OrderData，这个类跟order的只包含属性和Get和Set方法，他们包含分析模型中相应类的属性和关联，用于数据表现；OrderDAL，这个类用于数据库访问，帮助cOrderData实现类的持久化，辅助cOrder实现业务逻辑。
大家觉的如何?

 

一

一

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2005-01-15

• #2

在分析阶段中的实体类，到了设计阶段会衍生出多个类。假设这个实体类叫做order，那么设计阶段应该具有这样几个类：OrdebBLL，这个类用于实现order的业务逻辑，它包含分析模型中相应类的职责；OrderData，这个类跟order的只包含属性和Get和Set方法，他们包含分析模型中相应类的属性和关联，用于数据表现；OrderDAL，这个类用于数据库访问，帮助cOrderData实现类的持久化，辅助cOrder实现业务逻辑。
大家觉的如何?

 

李

李啸林

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2005-06-26

• #3

这种思路是好的。可有个问题，在实际项目中，实体类通常不止一个，如果对于每个实体都衍生出四五个类出来，是不是很麻烦？你又该如何处理类与类之间的关系呢？

 

I

InterPrise

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2005-08-11

• #4

我觉得怕麻烦不是一个好现象，只要这种思路和方法有利于分析和设计就可以了，实际上现在更多的作产品都是在画图。[]

 

X

xfz8124

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2005-08-11

• #5

好设计的关键就是干净整洁，代码相关性弱，好的设计总是把逻辑放在操作的数据附近，这种东西说得太多也不过就是纸上谈兵，实践出真知

 

L

logitech1229

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2005-09-28

• #6

楼上说的对，纸上谈兵都没用，编出经验后就得心应手了

 

J

jhwh

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2005-11-24

• #7

这样的设计有问题－－扩展性差。
需求不完全的情况下，知道会扩展，但是不知道怎样去扩展，那么这样的设计，到了后期，显然会对基类进行修改。于是，整个继承树以及打交道的其他类都需要修改，这也暴露了继承的问题：要用好派生类，必然对基类要了解－－耦合性太大。
如果你的类层次比较固定，简单的方法就是用visitor。如果这个也要变，用接口。软件很复杂？这个也搞不定？还不行？那就得动用policy了。
明星推荐：policy！！！
好处：可以完全扩展，不用修改写好的代码；即使修改代码，也不会对其他部分产生影响。
坏处：编写比较困难，比较废时间；用template来作比较好，但是delphi不支持:-(((。改用BCB吧：－）））