高内聚低耦合的软件设计

      如何才能设计出高质量、高水平的软件来？什么才是高质量、高水平的软件呢？高质量，高水平的软件应当是易于维护、易于适应变更、可重用性好的一个系统。如何才能做到这一点，答案是“高内聚低耦合”。 

        低耦合就是软件在构造的时候，各个模块、各个功能、各个类都不会过度依赖于它周围的环境。只有这样，才能使我们的模块（功能、类）在周围发生变更时不受影响，做到易于维护和易于适应变更。正因为如此，也使它更易于重用到其它功能类似的环境中，提高了重用性。

      高内聚则使软件中的各个模块（功能、类）能够各尽其能而又充分合作，也就是对于软件问题空间中需求的各个功能，系统可以合理地把它分配给各个模块（功能、类）来共同完成，而不是一个或几个八面玲珑、包打天下的超级类一个人完成。而对于该系统中的某一个模块（功能、类），具有自己高度相关的职责，即该职责中的几个任务是高度相关的。每一个模块（功能、类）都决不去完成与自己无关职责的任务。

      现在软件开发技术日新月异，不断得有新技术的出现，新的框架等。纵观这些技术或者是框架，无外乎是为了实现“高内聚低耦合”。当下在javaee开发中流行的ssh框架或者是.net开发中的不同的开发模式，这些技术的唯一目的是为了实现模块之间的低耦合。以便实现易于维护，易于适应变更，可重用性好的系统。

       Javaee的开发中，时下最流行的框架结构之一的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，如何执行的操作，与我无关。

      但是，当当只依赖于框架是否能够做到“高内聚低耦合”呢？回答是否定的。正是现在技术更新的比较快，就拿ssh框架来说，spring2与spirng3就有很大的不同。可能你用spring2搭建的框架想要升级到spring3可能并不是那么容易的，因为你过多的依赖了spirng2中提供的函数（当然，如果你事先考虑了这个问题当然是可以避免的）。另一方面是客户需求的改变，引用一句经典的话“我看到时我的需求就变更了。（I changed just when I saw it.）”过去我们用需求说明书来限定客户的需求（这也是一个深深印在我脑中的不良思维习惯），现在我们不能再这样做啦。我们能做的只是尽量让我们的软件耦合度降到最低以适应客户的需求。