追求代码质量 - 谨防紧密耦合！

在过去一年的时间中，我在“ 追求代码质量 ” 专栏撰写了大量的文章。这 些文章向大家介绍了许多可以改进代码质量的工具和技巧。我已经向大家展示了 如何应用代码度量来监控代码库的质量；如何使用 TestNG、FIT 和 Selenium 之类的测试框架来检验应用程序的功能；以及如何使用 XMLUnit 和 StrutsTestCase 之类的扩展框架（和一些功能强大的帮助工具，如 Cargo 和 DbUnit）来扩展测试框架的应用范围。

虽然代码度量和开发人员测试对于在整个开发过程中确保代码质量非常重要 （就像我经常所说的，要及时并经常进行测试），但是它们基本上只能对代码质 量做出反应。您通过测试和度量代码来确定和量化代码的质量，但是代码本身都 已经写好了。不论您做出何等努力，都会受困于最初的设计。

当然，不同的方法所设计出来的软件系统会有好有坏，良莠不齐。优秀设计 的关键因素之一就是注意保持系统的可维护性。粗劣设计的并可执行的系统可能 易于编写，但是要对它们提供支持确实是一个挑战。这些系统往往脆弱不堪，也 就是说对系统中某个区域的修改将会影响到其它看上去毫不相干的区域，因此要 对它们进行重构也相当的困难和耗时。向代码库中添加开发人员测试可以为我们 提供工作的规划，但是其进展本身仍然是一个艰苦和缓慢的过程。

我们可以通过重构来改进已经编写好的代码，但是通常来说在代码已完成之 后再进行改动花费巨大。而如果在一开始就把代码编写得 尽善尽美 会不会更加 方便和轻松呢？ 这个月，我将介绍一种非常主动的技巧，可以确保软件系统的 质量和可维护性。依赖性倒置原则 被证明是编写可维护和可测试的高质量代码 的必要条件。依赖性倒置原则的基本思想就是对象应该依赖于抽象 而不是实现 。

是依赖性倒置 而不是依赖性注入

依赖性倒置原则与依赖性注入并没有直 接的关系。依赖性注入，也被称作控制反转（inversion of control，IOC)，即 使用 Spring 之类的框架在运行的时候（而不是在编译的时候）链接对象的依赖 关系。虽然依赖性倒置和依赖性注入并不需要同时使用，但是它们是互补的：两 个技巧都力争利用抽象而不是实现。

过于紧密的耦合

您可能至少听说过面向对象编程中所使用的术语耦合（coupling）。耦合即 应用程序中各组件（或各对象）间的相互关系。松散耦合的应用程序要比紧密耦 合的应用程序更具模块化。松散耦合应用程序中的组件依赖于各种接口和抽象类 ，而紧密耦合的系统则与之相反，其组件依赖于各种具体的类。在松散耦合的系 统中，其组件是使用抽象而不是 实现来相互关连的。

如果有图解的话，可以很轻松地理解紧密耦合的问题。举例说明，图 1 中的 软件系统的 GUI 与它的数据库相耦合：

图 1. 一个紧密耦合的系统

GUI 对某个实现（而不是抽象）的依赖会对系统造成限制。在数据库未启动 和运行的情况下 GUI 是无法执行的。从功能的角度上看这种设计似乎并不是很 糟糕 —— 毕竟，我们一直都是这样编写应用程序而且也没有出什么问题 —— 但是测试就要另当别论了。

‘脆弱’ 的系统

图 1 中的系统使得隔离编程格外地困难，而这对测试和维护系统各个方面又 十分必要。您将需要一个具有正确查找数据的活动数据库来测试 GUI，和一个运 行正常的 GUI 来测试数据访问逻辑。您可以使用 TestNG-Abbot（现在的名称为 FEST）来测试前端，但是这样仍然无法告诉您任何有关数据库功能的内容。

清单 1 展示了这种糟糕的耦合。GUI 的一个特定的按钮定义了一个 ActionListener，它通过 getOrderStatus 调用直接与底层数据库通信。

清单 1. 把 ActionListener 定义为 GUI 中的一个按钮

fi

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!