public　 interface　WidgetDAO　{ 　 public　String　getOrderStatus(String　widget); 　 //.... }

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

GUI 的 ActionListener 代码引用接口类型 WidgetDAO（定义在清单 3 中） 而不是接口的实际实现。在清单 4 中，GUI 的 getOrderStatus() 方法在本质 上指定的是 WidgetDAO 接口：

清单 4. GUI 依赖于抽象，而不是数据库

private　String　 getOrderStatus(String　value)　{ 　 return　dao.getOrderStatus(value); }

对 GUI 完全隐藏了这个接口的实际实现，因为它是通过一个工厂来请求实现 类型的，如清单 5 所示：

清单 5. 对 GUI 隐藏了 WidgetDAO 实现

private　WidgetDAO　 dao; //... private　void　initializeDAO()　{ 　 this.dao　=　WidgetDAOFactory.manufacture(); }

进展顺利

注意，清单 5 中的 GUI 中的代码只引用接口类型 —— GUI 中的任何地方 都没有使用（或导入）接口的实现。这种对实现细节的抽象是灵活性的关键：它 使您能够更换实现类型，而完全不会影响到 GUI。

还要注意，清单 5 中的 WidgetDAOFactory 是如何使 GUI 避开 WidgetDAO 类型的创建细节的。这些是工厂的任务，如清单 6 所示：

清单 6. 工厂对 GUI 隐藏了实现细节

public　class　 WidgetDAOFactory　{ 　 public　static　WidgetDAO　manufacture(){ 　 //.. 　 } }

使 GUI 引用对某个接口类型的数据检索可以为创建不同的实现提供灵活性。 在这种情况下，部件信息保存在数据库中，因此可以创建一个 WidgetDAOImpl 类与数据库直接通信，如清单 7 所示：

清单 7. WidgetDAO 类型的任务

public　class　WidgetDAOImpl　 implements　WidgetDAO　{ 　 public　String　getOrderStatus(String　value)　{ 　 //... 　 } }

注意，实现代码并未包含在这些例子中。这些代码并不重要，真正有价值的 是原理。您不应该关心 WidgetDAOImpl 的 getOrderStatus() 方法是如何运作 的。它可以从数据库或者从某个文件系统中获得状态信息，但重点是这不会对您 产生什么影响！

现在，分离 GUI

因为 GUI 现在依赖于某个抽象并且通过一个工厂来获得该抽象的实现，所以 我们可以轻易地创建一个没有与数据库或者文件系统相耦合的模仿类。模仿类用 于分离 GUI，如清单 8 所示：

清单 8. 分离变得简单

public　class　MockWidgetDAOImpl　 implements　WidgetDAO　{ 　 public　String　getOrderStatus(String　value)　{ 　　 //.. 　 } }

添加一个模仿类是设计可维护性的系统的最后一个步骤。把 GUI 与 数据库 分离开来意味着我们可以测试 GUI 而无需关心特定的数据。我们还可以测试数 据访问逻辑而无需关心 GUI。

结束语

您可能没有过多地考虑这些，但是您如今所设计和构建的应用程序使用寿命 可能非常长久。您将继续开发其它的项目，或者在其它的公司工作，但是您的代 码（如 COBOL）将会留下来，甚至有可能使用几十年。

开发人员所赞同的一点是：编写良好的代码易于维护，依赖性倒置原则是进 行可维护性设计的可靠方法。依赖性倒置注重依赖于抽象（而非实现），这样可 以在同一个代码库中创建大量的灵活性。借助一个 DAO 来应用这个技巧，就如 您这个月所看到的，不仅可以确保您能够在需要的时候修改代码库，还可以使其 它的开发人员修改代码库。

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