充满诗意的联盟

问题的提出

我常常在思考一个问题，我们如何能设计出高水平、高质量的软件出来。怎样是高水平、高质量的软件？它应当是易于维护、易于适应变更、可重用性好的一个系统。如何做到这一点呢？答案当然是“低耦合、高内聚”了。低耦合就是软件在构造的时候，各个模块、各个功能、各个类都不会过度依赖于它周围的环境。只有这样，才能使我们的模块（功能、类）在周围发生变更时不受影响，做到易于维护和易于适应变更。正因为如此，也使它更易于重用到其它功能类似的环境中，提高了重用性。高内聚则使软件中的各个模块（功能、类）能够各尽其能而又充分合作，也就是对于软件问题空间中需求的各个功能，系统可以合理地把它分配给各个模块（功能、类）来共同完成，而不是一个或几个八面玲珑、包打天下的超级类一个人完成。而对于该系统中的某一个模块（功能、类），具有自己高度相关的职责，即该职责中的几个任务是高度相关的。每一个模块（功能、类）都决不去完成与自己无关职责的任务。

那么怎样能构造一个低耦合、高内聚的系统能，时下最流行的框架结构之一的struts+spring+hibernate为我们提供了方便。使用struts我们可以应用MVC模型，使页面展现与业务逻辑分离，做到了页面展现与业务逻辑的低耦合。当我们的页面展现需要变更时，我们只需要修改我们的页面，而不影响我们的业务逻辑；同样，我们的业务逻辑需要变更的时候，我们只需要修改我们的java程序，与我们的页面无关。使用spring我们运用IoC（反向控制），降低了业务逻辑中各个类的相互依赖。假如类A因为需要功能F而调用类B，在通常的情况下类A需要引用类B，因而类A就依赖于类B了，也就是说当类B不存在的时候类A就无法使用了。使用了IoC，类A调用的仅仅是实现了功能F的接口的某个类，这个类可能是类B，也可能是另一个类C，由spring的配置文件来决定。这样，类A就不再依赖于类B了，耦合度降低，重用性提高了。使用hibernate则是使我们的业务逻辑与数据持久化分离，也就是与将数据存储到数据库的操作分离。我们在业务逻辑中只需要将数据放到值对象中，然后交给hibernate，或者从hibernate那里得到值对象。至于用Oracle、MySQL还是SQL Server，如何执行的操作，与我无关。

然而我要说的是，即使我们使用了struts+spring+hibernate框架构建我们的软件，就可以做到“低耦合、高内聚”了吗？我认为这是远远不够的！我认为我们在使用struts+spring+hibernate框架的时候常常会有以下几个问题值得改进。

分析与决策

1.       编写DAO的时候不要直接去使用hibernate或spring对hibernate的支持。

2.       编写Action的时候不要直接使用spring和spring的继承类

3.       当BUS需要获取别的模块的数据的时候，不要直接去使用该模块的DAO

总结：从技术升级和需求变更两方面适应变化

软件开发专家Alistair Cockburn在《敏捷软件开发》中说过，软件在整个生命周期中变更是无时无刻不发生的。我认为，软件的变更一方面是技术的更新，今天我们使用struts+spring+hibernate，明天呢，我们将使用什么呢？正因为技术变更得太快，我们的系统应当不要太依赖于某个具体的技术或框架，以便于明天的技术更新。同时，来自客户的需求变更也是我们必须面对的另一个压力。一句经典的话是这样描述客户的变更：“当我看到时我的需求就变更了。（I changed just when I saw it.）”过去我们用需求说明书来抑制用户的变更，现在发现不能这样了。敏捷软件开发提出了许多应对用户变更的办法，其中建立低耦合高内聚的软件结构也是办法之一。系统中的所有对象都有自己的明确职责，这个职责应当不多且高度相关。每个对象都应当只完成自己的职责，而把其它的任务交给别人去做。正如我前面提到的例子，评审表对象只完成与评审表相关的操作，而在它需要完成的任务中，需要使用评审计划数据的相关功能，交给评审计划对象去完成，评审表只管调用。这样的构造要求开发者相互协调，彼此多交流，同时，也需要有人来统一规划，站在全局的设计这个系统。通过这些，我们才可以适应变化，提高设计水平。