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

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


模板方法（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();
}
假定系统已经投运，用户提出新的需求，要求加上信用卡支付和支票支付，我们将怎样处理呢？如下图所示。这样就减少了系统的耦合性。而在系统升级的时候，并不需要改变原来的代码。