系统已投运，用户提新需求！如何不改变结构又实现业务流扩展?

Posted 2020-09-08

软件复用的关键是寻找相似性，如果相似性表现为业务流程相似，但是业务单元具有特殊性，就可以定义一个操作中的业务流程骨架，而通过一个接口将一些业务单元的实现延伸到实现类中去，使得可以不改变一个业务流程的结构，即可重新定义该业务流程的某些特定业务单元。目前，已经有多种设计解决方案可以实现业务流扩展。

模板方法（Template Method）解决方案

模板方法（Template Method）解决方案的意图是在抽象类为操作定义了一个算法的骨架，将其中一些步骤推迟到子类中实现，这就可以在不改变算法的结构的情况下，重新定义该算法的细节。不同的子类可以以不同的方式实现这些抽象方法，从而可以对剩余的逻辑有不同的实现。这就提供了一个很好的代码复用平台，并且可以适应具体方法的变化，如下图所示。

模板方法内说明代码如下：

public abstract class Payment{

………….

public String goSale(){

String x = "不变的流程一";

x += Action(); //可变的流程

x += amount + ", 正在查询库存状态"; //属性和不变的流程二

return x;

}

public abstract String Action();

}

假定系统已经投运，用户提出新的需求，要求加上信用卡支付和支票支付，可以立刻加以升级。

桥梁（Bridge）解决方案

桥梁（Bridge）解决方案与模板方法（Template Method）解决方案所解决的问题是类似的，但是模板方法使用了继承，但桥梁使用了聚集，所以是更符合设计原则的。我们可以通过一个关于支付的简单例子可以说明它的原理。

说明代码如下。

public class Payment{

……

private Implementor imp;

public void setImp(Implementor s){

imp=s;

}

public String goSale(){

String x = "不变的流程一";

x += imp.Action(); //可变的流程

x += amount + ", 正在查询库存状态"; //属性和不变的流程二

return x;

}

}

interface Implementor{

public String Action();

}

假定系统已经投运，用户提出新的需求，要求加上信用卡支付和支票支付，我们将怎样处理呢？如下图所示。这样就减少了系统的耦合性。而在系统升级的时候，并不需要改变原来的代码。

本文出自 “中科院计算所培训” 博客，谢绝转载！