Java应用架构设计的七次重构详解

Java应用架构设计的七次重构详解

在开发系统时，虽然一个很小的系统，开始时它也是粗粒度和重量级的模块；当特定的需要出现时，我们将会把较大的模块儿拆分为较细粒度和轻量级的模块，他们会处理特定的功能性和非功能性需求。而七次重构就是从一个系统出发，根据软件使用中不断出现的新需求教你如何实现一个灵活的应用架构。

下面以开发一个处理账单支付的系统为例进行讨论。在支付账单前，系统需要根据与领款人写协议，针对这个账单采用一个折扣率（我们将这个过程称为审核账单）。计算这个折扣率需要使用到第三方供应商进行计算。另外还需要与遗留的财务系统进行集成，将会为这个系统提供用于对账的支付信息。随着开发过程的进行，我们将不断重构，不断完善细节。

原始版本

类图如下

从类图中可以看到，有一些使用Struts的Action和ActionForm类。还有一些Java ServerPage（JSP）在这里没有进行展示。Customer类有一个Bill实例的列表，每个Bill分别有对AuditFacade和Payment类的引用。AutitFacade会集成第三方供应商的软件计算折扣，Payment类会集成一个遗留的财务系统。注意Bill类与AuditFacade之间的双向关联；后面我们会处理这种问题。

第一次重构

物理分层模式：对于真有分层的系统，我们可以将每层拆分为一个独立的模块，而且上层模块依赖低层模块，但不能相反；我们只需要修改构建脚本就能将分层拆分为单独的JAR文件。第一次重构就是将业务对象和数据访问层拆分到单独的模块中：

第二次重构

抽象化模块模式：用来解除双向依赖的。

在第一幅图中，Bill类与AuditFacade类之间存在双向关联。这个设计存在的问题是，Bill类会与具体的AuditFacade类紧密耦合，而且关系是双向的。下面的程序中描述了Bill类的audit方法：

public void audit(){
    AuditFacade auditor=new AuditFacade();
    this.billDate.setAuditedAmount(auditor.audit(this));
    this.persist();
}

在这里，audit方法实际上会创建AuditFacade、调用其audit方法并传递一个队Bill的引用。这很不好，我们将用抽象化模块模式来改善它。首先把AuditFacade重构为一个接口并创建一个单独的AuditFacade1实现，为了解决Bill类与AuditFacade1紧密耦合，我们将AuditFacade接口传递进Bill的audit方法中，这样我们可以切换AuditFacade实现。下图展现了这种模块细分和修改后的代码

!

public void audit(AuditFacade auditor){
    this.billData.setAuditedAmount(auditor.audit(this));
    this.persist();
}

第三次重构

非循环关系模式：解除循环依赖

第二次重构之后，bill.jar模块和audit.jar模块之间存在循环依赖，为了解除这种循环依赖，我们可以再将Bill类中的用于处理audit方法的部分抽象为一个接口Auditable，这样类之间的非循环关系如下所示

重构之后的非循环关系模块图如下

注意， 接口要更接近使用它的类，而远离实现它的类。

第四次重构

分离抽象模式：将抽象与实现它们的类分离

如果我们想部署新的AuditFacade的实现，我们有两个选择：将其打包到以后的audit.jar模块中或者将其部署到新的模块中。其中第二个方案更灵活，因为我们不需要修改已有的audit.jar模块。如果是第一种方案，新部署AuditFacade实现就需要修改以前的模块。为了解决这个问题，就需要用到分离抽象模式。
分离抽象之后的模块图如下：

第五次重构

就近异常模式：异常应该接近抛出他们的类（或接口）

第六次重构

上移：将依赖提升到一个更高的模块

现在有两个类：A和B，如果A依赖B，而新需求只需要A，为了不部署B，我们可以创建C，同时依赖A，B，完成A的部分功能（具体是依赖B的功能），这样完成了依赖上移。

第七次重构

工厂模式：应该使用工厂创建模块中的实现类。