blues
2003-04-19 22:30
"低耦合"是系统设计/实现的一个追求目标。到项目后期,太多的耦合导致的后果是:一点小的修改就要引发众多模块的修改,以及测试--最要命的是所有模块都要测试。如果这个后果出现,就等于宣布这个项目失败。

设计/实现过程的一个原则是:最好0耦合;不行就追求单向耦合。

怎样追求低耦合--总结出几种情况,(个人浅见,欢迎讨论)

1. 子系统A和子系统B之间没有逻辑联系,相对独立--0耦合,最好

2. A和B都要依赖于一些共同的东西,A<-->B。能否转换为如下结构?

A-->C; B-->C

如果能,OK,单向耦合。

3. 如2的情形,如果不好抽取C模块出来,那么能否将A的一些功能转移到B中,形成A依赖于B,B依赖于本身?

A-->B;B-->B ==> A->B

如果能,OK,单向耦合。

4.如3情形,如果不行,则考虑模块内是否分层次?(一般会有的,例如:Businesslogic -->domain -->DAO),那么能否将耦合的层次降低:从businesslogic 耦合 -->变成domain耦合 -->变成DAO层耦合?

5.如果都不行,那就要回过头来想想整个设计方案哪里出问题了。是整体设计方案不合理,不在本贴考虑范围之内了。

blues
2003-04-19 22:42
persistence 技术(entity bean, ojb等等)大家都爱用,但这个技术在某些情况下不适用。例如在"查询"模块,因为查询说到底是sql语句的干活,而sql语句的优化是和不同数据库紧密相关的,一定需要DBA参与的。另一方面,查询不需要修改数据,那就用不上persistence的好处了。

--说这个,是想说明一点:做软件的既要有先进的技术理论,还需要就事论事,遇到什么事情就出什么招。就象"设计模式"那么强调"context"一样。否则项目难免失败。

blues
2003-04-19 22:56
"设计模式"强调其适用的情景,而其中有个最重要的"情景"好象容易被人忽略。

----明确的功能需求

----定义明确的接口

----定义明确的Entity Relation

----and more...

一味强调“设计模式”容易陷入舍本逐末的状态。

有明确的系统定义,不一定项目就成功;但没有有明确的系统定义,项目一定会失败,不管我们设计模式用得多精巧。

地平线
2003-12-30 10:43
--数据库表-对象映射方案

是说这方案不好么?

那最好是怎么样处理数据库表与对象的关系呢?

wxlin2k
2003-12-30 23:33
拜托,不懂不要乱译好不好,人家是说

你会惊奇地发现,他们甚多东西都不是按本子办事(原文直译:做了很多书本上会规划为错误的做法),但是,他们的办事效率要比同行们高得多....

猜你喜欢
3Go 上一页 1 2 3