问题的提出
我常常在思考一个问题，我们如何能设计出高水平、高质量的软件出来。怎样是高水平、高质量的软件？它应当是易于维护、易于适应变更、可重用性好的一个系统。如何做到这一点呢？答案当然是“低耦合、高内聚”了。低耦合就是软件在构造的时候，各个模块、各个功能、各个类都不会过度依赖于它周围的环境。只有这样，才能使我们的模块（功能、类）在周围发生变更时不受影响，做到易于维护和易于适应变更。正因为如此，也使它更易于重用到其它功能类似的环境中，提高了重用性。高内聚则使软件中的各个模块（功能、类）能够各尽其能而又充分合作，也就是对于软件问题空间中需求的各个功能，系统可以合理地把它分配给各个模块（功能、类）来共同完成，而不是一个或几个八面玲珑、包打天下的超级类一个人完成。而对于该系统中的某一个模块（功能、类），具有自己高度相关的职责，即该职责中的几个任务是高度相关的。每一个模块（功能、类）都决不去完成与自己无关职责的任务。
那么怎样能构造一个低耦合、高内聚的系统能，时下最流行的框架结构之一的struts+spring+hibernate然而我要说的是，即使我们使用了struts+spring+hibernate
分析与决策
1. 编写DAO的时候不要直接去使用hibernate或spring对hibernate的支持。
现在我们在编写DAO以上问题，究其原因，是我们项目中的DAO
2. 编写Action的时候不要直接使用spring和spring的继承类
前面我说了应当避免DAO的继承类然后使用它的方法。如此的使用，我们的Action将依赖与spring。我们同样可以使用一个叫BasicAction的父类，然后用一个接口来隔离spring。由于ActionBasicAction中，提高系统的可维护性。
3. 当BUS需要获取别的模块的数据的时候，不要直接去使用该模块的DAO
我举一个简单的例子：我需要设计一个软件评审的管理软件，该软件分为评审组织者制订评审计划、评审者分别填写评审表后由评审组织者汇总评审表、评审组织者制作评审报告。这是一个非常简单的项目，分成了三个人来完成。但是项目进行快结束的时候却出现了问题。填写评审表需要获得评审计划中的一些数据，制作评审报告的数据来源于评审表。项目组在开始编程前先开了一次会，大家约定好了各个部分的数据格式及其规则，然后开始工作。然而数天后项目组把各个模块整合以后发现，系统根本跑不起来，为什么呢？设计评审计划的人发现，所有评审计划应当按照产品编号来进行管理而不是项目编号。由于这个变更，填写评审表模块在待评审列表中什么都无法显示；同样，设计评审表的人发现，在一个评审计划中评审表与评审者不是一对多的关系，而是一对一的关系，因而修改了这两个表的关联。因为这样，在制作评审报告时就不能正确得到评审表数据。其实一个软件项目在整个进行过程中总是不断变更。我们需要做的不是去抑制这些变更，而应当是通过软件的结构去适应这些变更，即是降低各模块间的依赖（耦合），提高内聚。
拿这个实例来说，当评审表需要调用评审计划的数据的时候，不应当是自己写一个DAO去调用评审计划的数据，而应当是调用评审计划的接口，将这个任务交给评审计划类来完成。当评审报告需要调用评审表的数据的时候，同样应当去调用评审表的接口，由评审表来实现。同时，这种调用应当是去调用BUS层的接口。为什么呢？比如在评审计划中的一个业务逻辑是只有在评审计划发布以后才能制作评审表，那么怎样才是已发布的评审计划呢？这个业务逻辑应当由谁来定义？当然是评审计划。在什么地方定义？当然是BUS而不是DAO，因为DAO仅仅是实现数据的持久化，而BUS才是实现业务逻辑的地方。既然如此，如果评审表去调用评审计划的DAO，那么已发布评审计划的业务逻辑必然包含在了评审表的业务逻辑里了。我们假设有一天，已发布评审计划的业务逻辑发生变更了（实际上这样的会在你毫不经意间就发生了），编写评审计划的人会很快就修改了评审计划的业务实现并且测试通过了。他不知道评审表里也包含了这样的业务逻辑，因而修改后的程序在运行到评审表的时候就很可能会出错。不幸的是，在实际工作中，同样一个业务逻辑可能包含在无数个你可能知道，但你也可能不知道的代码中。这样的结构就是一个不易于维护的差的结构。
总结：从技术升级和需求变更两方面适应变化
软件开发专家Alistair Cockburn相关链接：回复：《如何在struts+spring+hibernate的框架下构建低耦合高内聚的软件》。
| Spring-Hibernate.rar |
| 描述: |
|
下载 |
| 文件名: |
Spring-Hibernate.rar |
| 文件大小: |
9 KB |
| 下载过的: |
文件被下载或查看 511 次 |