软件复用的关键是寻找相似性,如果相似性表现为业务流程相似,但是业务单元具有特殊性,就可以定义一个操作中的业务流程骨架,而通过一个接口将一些业务单元的实现延伸到实现类中去,使得可以不改变一个业务流程的结构,即可重新定义该业务流程的某些特定业务单元。目前,已经有多种设计解决方案可以实现业务流扩展。
模板方法(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();
}
假定系统已经投运,用户提出新的需求,要求加上信用卡支付和支票支付,我们将怎样处理呢?如下图所示。这样就减少了系统的耦合性。而在系统升级的时候,并不需要改变原来的代码。