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

清单 2 中的代码出现了问题，尤其是它通过一个硬编码的 SQL 语句直接与一个硬编码的数据库进行通信。Yeeesh! 您能够想像开发人员测试这种 GUI 和相关数据库的挑战吗（顺便说一下，测试本应该简单得像测试一个 Web 页面一样）？ 倘若对数据库的任何改动都将 影响到 GUI，那么要考虑修改系统的话会使情况变得更糟。

DAO 模式 Data Access Object (DAO) 是一种设计模式，它旨在使用接口和相关实现把低级的数据访问操作从高级事务逻辑中分离出来。从本质上说，某个具体的 DAO 类通过特定的数据源实现访问数据的逻辑。DAO 模式使得只使用一个接口为多个数据库，或者甚至各种不同的数据源（如文件系统）定义多个具体实现成为了可能。

转变为松散耦合!

现在在脑海中考虑一下使用依赖性倒置原则设计的相同的系统。如图 2 所示，通过向应用程序添加两个组件来解除应用程序中的耦合是可能的：这两个组件分别是一个接口和一个实现：

在图 2 所示的应用程序中，GUI 依赖于一个抽象 —— 一个数据访问对象或 DAO。DAO 的执行直接依赖于数据库，但是 GUI 本身并没有陷入其中。以 DAO 的形式添加一个抽象可以从 GUI 实现将数据库实现解耦。一个接口会替代数据库与 GUI 代码相耦合。清单 3 显示了该接口。

清单 3. WidgetDAO 是一个能帮助解耦架构的抽象

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

清单 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 所示：

文章来源于领测软件测试网 https://www.ltesting.net/