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

核心提示： GUI 的 ActionListener 代码引用接口类型 WidgetDAO（定义在清单 3 中）而不是接口的实际实现，在清单 4 中，追求代码质量: 谨防紧密耦合！(5)，GUI 的 getOrderStatus() 方法在本质上指定的是 WidgetDAO 接口：清单 4. GUI 依赖于

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 来应用这个技巧，就如您这个月所看到的，不仅可以确保您能够在需要的时候修改代码库，还可以使其它的开发人员修改代码库。