单元测试和设计模式在重构中的应用

单元测试和设计模式在重构中的应用

本文结合一个事例谈谈设计模式在重构中的应用。在重构过程中，单元测试发挥了很大的作用。这是一个报表系统，每天将公司分散在各处的数据收集产生各种报表。本文只拿出系统的数据访问层面做例子。 

系统需要处理的数据源比较多，系统中建立了一个Connection Pool对这些数据源进行管理，外界使用一个数据源的名称，从Connection Pool中得到相应的数据库连接。按照系统最初的设计，所有的数据源都是Sql Server类型的。数据访问层的大体结构如下： 

 

图中的DBConnection负责处理Sql Server的查询和更新等等操作。程序开发采用了单元测试的模式，对DBConnection建立了相应的测试程序。 

随着开发的进行，调查客户的业务环境得到了新的信息，客户的报表不仅需要从Sql Server中取数，还有别的类型的数据源，目前知道的有Oracle数据库。可以很不幸的说，我们被残酷的现实“捉弄”了一次。但是我们被捉弄了一次，决不能再被捉弄第二次。 

在添加新的数据访问模块之前，我们必须先重构现有的系统，使之适应多种数据源的访问。在这个过程中很容易就想到了Factory模式。 

首先要做的是：解除ConnectionPool和DBConnection之间的直接联系，建立一个数据库连接的接口。于是另外建立了一个SqlDBConnection类，将DBConnection中的实现全部转移到了SqlDBConnection中，修改DBConnection将其定义为一个Interface。 

然后，建立一个ConnectionFactory，ConnectionPool建立数据源连接时候从Factory中得到具体的连接类型。在这一系列过程中，单元测试一直在验证的系统的正确性。有必要修改和补充一些Test case. 

现在系统的结构如下： 

 

在重构的过程中，单元测试发挥了很大的作用。测试保证了每一步重构都是正确的。这只是一个简单的重构，如果情况稍有复杂，在没有单元测试的情况下进行重构简直是不可能的。 

现在万事具备，我们可以将新的数据访问模块接在系统上了： 

 

从这个系统中，我的体会是：系统的设计一开始不一定要是最完备的，不必在一开始就设计的过于复杂。但是一定要留下一定的灵活性，一旦情况需要，该重构就要重构，不能在开发过程中就象打补丁一样添加新的功能。同时，单元测试在重构的过程中非常重要，单元测试是对重构正确性的一种验证。