模板方法模式实现探讨

模板方法(Template Method)模式是GOF设计模式中最为常见几个模式之一。现在流行的很多框架中(如Spring，struts等)，我们都可以看到模板方法模式的广泛应用。模板方法模式主要应用于框架设计中，在日常的应用设计中也被经常使用。
   可是，我们在运用模板方法模式来解决我们的需求而进行设计时，往往忽略了一些非常重要的细节。保证架构逻辑的正常执行，不被子类破坏；怎么让子类扩展模板方法等。

1. 模板方法设计模式的意图
通常我们会遇到这样的一个问题：我们知道一个算法所需的关键步聚，并确定了这些步聚的执行顺序。但是某些步聚的具体实现是未知的，或者是某些步聚的实现与具体的环境相关。
模板方法模式把我们不知道具体实现的步聚封装成抽象方法，提供一些按正确顺序调用它们的具体方法(这些具体方法统称为模板方法),这样构成一个抽象基类。子类通过继承这个抽象基类去实现各个步聚的抽象方法，而工作流程却由父类来控制。

考虑一个简单的订单处理需求:一个客户可以在个订货单中订购多个货物(也称为订货单项目)，货物的销售价是根据货物的进货价进行计算的。有些货物可以打折的，有些是不可以打折的。每一个客户都有一个信用额度，每张订单的总价不能超出该客户的信用额度。

根据上面的业务，我们可以知道处理一个订单需要的步聚:
1. 遍历订货单的订货单项目列表，累加所有货物的总价格(根据订货单项目计算出销售价)
2. 根据客户号获得客户的信用额度
3. 把客户号，订单的总价格，及订单项目列表写入到数据库

但是我们并不能确定怎么计算出货物的销售价，怎样根据客户号获得客户的信用额度及把订单信息写入数据库这些方法的具体实现。
所以用一个抽象类AbstractOrder确定订单处理的逻辑，把不能确定的方法定义为抽象方法,由子类去完成具体的实现。

public abstract class AbstractOrder {
   public Order placeOrder(int customerId , List orderItemList){
int total = 0;
for(int i = 0; i < orderItemList.size();i++){
   OrderItem orderItem = (OrderItem)orderItemList.get(i);
   Total  += getOrderItemPrice(orderItem) * orderItem.getQuantity();
}
if(total > getSpendingLimit(customerId)){
  throw new BusinessException(“超出信用额度” + getSpendingLimit(customerId));
}

int orderId = saveOrder(customerId, total, orderItemList);
return new OrderImpl(orderId,total);

   }
   
   public abstract int getOrderItemPrice(OrderItem orderItem);
   public abstract int getSpendingLimit(int customerId);
   public abstract int saveOrder(int customerId, int total, List orderItemList);
}

AbstractOrder在placeOrder方法中确定了定单处理的逻辑，placeOrder方法也称为模板方法。在placeOrder中调用了三个抽象方法。子类只需要去实现三个抽象方法，而无需要去关心定单处理的逻辑。

2．模板方法模式定义及结构
模板方法模式属于行为模式的一种(GOF95)。准备一个抽象类，定义一个操作中的算法的骨架，将一些步聚声明为抽象方法迫使子类去实现。不同的子类可以以不同的方式实现这些抽象方法。
   模板方法模式的静态结构图

在模板方法模式中有两个参与者进行协作。
抽象模板类：定义一个或多个抽象操作，由子类去实现。这些操作称为基本操作。
定义并实现一个具体操作，这个具体操作通过调用基本操作给确定顶级逻辑。这个具体操作称为模板方法。
具体类：实现抽象模板类所定义的抽象操作。
如上面的订单处理所示：AbstractOrder就是抽象模板类，placeOrder即是抽象模板方法。GetOrderItemPrice，getSpendingLimit和saveOrder三个抽象方法为基本操作。
具体子类能过需要去实现这三个抽象方法。不同的子类可能有着不同的实现方式。

Public class ConcreteOrder extends AbstractOrder{
  
  public int getOrderItemPrice(OrderItem orderItem){
//计算货物的售价
……
  }
  public int getSpendingLimit(int customerId){
//读取客户的信用额度
…..
  }
public int saveOrder(int customerId, int total, List orderItemList){
  //写入数据库
……
}
}

ConcreteOrder为AbstractOrder的具体子类，ConcreteOrder需要去完成具体的三个基本操作。同时他也具有了父类一样的处理逻辑。把具体的实现延迟到了子类去实现，这就是模板方法模式所带来的好处。

3．模板方法模式与控制反转
  “不要给我们打电话，我们会给你打电话”这是著名的好莱坞原则。在好莱坞，把简历递交给演艺公司后就只有回家等待。由演艺公司对整个娱乐项的完全控制，演员只能被动式的接受公司的差使,在需要的环节中，完成自己的演出。模板方法模式充分的体现了“好莱坞”原则。由父类完全控制着子类的逻辑,这就是控制反转。子类可以实现父类的可变部份，却继承父类的逻辑,不能改变业务逻辑。

4．模板方法模式与开闭原则
  什么是“开闭原则”?
  开闭原则是指一个软件实体应该对扩展开放，对修改关闭。
也就是说软件实体必须是在不被修改的情况下被扩展。模板方法模式意图是由抽象父类控制顶级逻辑，并把基本操作的实现推迟到子类去实现,这是通过继承的手段来达到对象的复用，同时也遵守了开闭原则。
父类通过顶级逻辑，它通过定义并提供一个具体方法来实现，我们也称之为模板方法。通常这个模板方法才是外部对象最关心的方法。在上面的订单处理例子中，
public Order placeOrder(int customerId , List orderItemList) 这个方法才是外部对象最关心的方法。所以它必须是public的,才能被外部对象所调用。
子类需要继承父类去扩展父类的基本方法，但是它也可以覆写父类的方法。如果子类去覆写了父类的模板方法，从而改变了父类控制的顶级逻辑。这违反了“开闭原则”。我们在使用模板方法模式时，应该总是保证子类有正确的逻辑。所以模板方法应该定义为final的。
所以AbstractOrder 类的模板方法placeOrder方法应该定义为final

public final  Order placeOrder(int customerId , List orderItemList)

因为子类不能覆写一个被定义为final的方法。从而保证了子类的逻辑永远由父类所控制。

模板方法模式中,抽象类的模板方法应该声明为final的。

5.模板方法模式与对象的封装性
面向对象的三大特点：继承，封装，多态
对象有内部状态和外部的行为。封装是为了信息隐藏，通过封装来维护对象内部数据的完整性。使得外部对象不能够直接访问一个对象的内部状态，而必须通过恰当的方法才能访问。
在java语言中，采用给对象属性和方法赋予指定的修改符(public ,protected,private)来达到封装的目的，使得数据不被外部对象恶意的访问及方法不被错误调用从而破坏对象的封装性。

降低方法的访问级别，也就是最大化的降低方法的可见度是一种很重要的封装手段。最大化降低方法的可见度除了可以达到信息隐藏外，还能有效的降低类之间的耦合度,降低一个类的复杂度。还可以减少开发人员发生的的错误调用。
一个类应该只公开外部需要调用的方法。而所有为公开方法服务的方法都应该声明为protected或private。如是一个方法不是需要对外公开的方法，但是它需要被子类进行扩展的或调用。那么把它定义为protected.否则应该为private.
显而易见，模板方法模式中的声明为abstract的基本操作都是需要迫使子类去实现的，它们仅仅是为模板方法placeOrder服务的。它们不应该被AbstractOrder所公开，所以它们应该protected.

protected abstract int getOrderItemPrice(OrderItem orderItem);
protected abstract int getSpendingLimit(int customerId);
   protected abstract int saveOrder(int customerId, int total, List orderItemList);

模板方法模式中，基本方法应该声明为protcted abstract

6.模板方法模式与勾子方法(hookMethod)
上面讨论模板方法模式运用于一个业务对象。事实上，框架频繁使用模板方法模式，使得框架实现对关键逻辑的集中控制。
思考这样的一个需求：我们需要为基本Spring的应用做一个测试用例的基类.用于对类的方法进行单元测试。我们知道Spring应用把需要用到的对象都定义在外部的xml文件中，也称为context。通常我们会把context分割成多个小的文件，以便于管理。在测试时我们需要读取context文件，但是并不是每次都读取所有的文件。读取这些文件是很费时间的。所以我们想把它缓存起来，只要这个文件被读取过一次，我们就把它们缓存起来。所以我们通过扩展Junit的TestCase类来完成一个测试基类。我们需要实现缓存的逻辑，其它开发人员只需要实现读取配置文件的方法即可。它不用管是否具有缓存。

public AbstractCacheContextTests extends TestCase{
  private static Map contextMap = new HashMap();
  
  protected ConfigurableApplicationContext applicationContext;
  
  protected boolean hasCachedContext(Object contextKey) {
		return contextKeyToContextMap.containsKey(contextKey);
	}
	
	protected ConfigurableApplicationContext getContext(Object key) {
		String keyString = contextKeyString(key);
		ConfigurableApplicationContext ctx =
				(ConfigurableApplicationContext) contextKeyToContextMap.get(keyString);
		if (ctx == null) {
			if (key instanceof String[]) {
				ctx = loadContextLocations((String[]) key);
			}
			contextKeyToContextMap.put(keyString, ctx);
		}
		return ctx;
	}
	
		protected String contextKeyString(Object contextKey) {
		if (contextKey instanceof String[]) {
			return StringUtils.arrayToCommaDelimitedString((String[]) contextKey);
		}
		else {
			return contextKey.toString();
		}
	}
	
		protected ConfigurableApplicationContext loadContextLocations(String[] locations) {
		return new ClassPathXmlApplicationContext(locations);
	}
	
	//覆写TestCase的setUp方法，在运行测试方法之前从缓存中读取context文件,如果缓存中不存在则初始化applicationContext,并放入缓存.
	protected final void setUp() throws Exception {
	   String[] contextFiles = getConfigLocations();
	   applicationContext = getContext(contextFiles);
	   
	}
	
	//读取context文件，由子类实现
	protected abstract String[] getConfigLocations();

}

这样子类只需要去实现getConfigLocations方法，提供需要读取的配置文件字符数组就可以了。至于怎么去读取context文件内容，怎么实现缓存，则无需关心。
AbstractCacheContextTests保证在运行所有测试之前去执行读取context文件的动作。
注意这里setUp方法被声明为protected,是因为setUp方法是TestCase类的方法。在这里setUp方法被定义为final了，是确保子类不能去覆写这个方法，从而保证了父类控制的逻辑。
在这里我们就会发现一个问题了，如果你使用过Junit你就会明白发生了什么问题了。TestCase的setUp方法，就是在这个测试类的测试方法运行之前作一些初始化动作。如创建一些所有测试方法都要用到的公共对象等。我们在这里把setUp方法声明为final之后，子类再也无法去扩展它了，子类同时还需要一些额外的初始化动作就无法实现了。
可能你会说:“把setUp方法的final修饰符去掉就可以了啊”。这样是可以的，但是去掉final修饰符后，子类是可以覆写setUp方法，而去执行一些额外的初始化。而可怕的是，父类从此失去了必须读取context文件及缓存context内容的逻辑。
为了解决这个问题，我们实现一个空方法onSetUp。在setUp方法中调用onSetUp方法。这样子类就可以通过覆写onSetUp方法来进行额外的初始化。



//覆写TestCase的setUp方法，在运行测试方法之前从缓存中读取context文件,如果缓存中不存在则初始化applicationContext,并放入缓存.

protected final void setUp() throws Exception {
	   String[] contextFiles = getConfigLocations();
	   applicationContext = getContext(contextFiles);
	   
       onSetUp();
	}
	
protected void onSetUp(){
 
}
	//读取context文件，由子类实现
	protected abstract String[] getConfigLocations();

}

为什么不把onSetUp声明为abstract呢？这是因为子类不一定总是需要覆写onSetUp方法。可以说onSetUp方法是为了对setUp方法的扩展。
像onSetUp这样的空方法就称之为勾子方法(HookMethod);

7.模板方法模式与策略模式
  模板方法模式与策略模式的作用相常类似。有时可以用策略模式替代模板方法模式。模板方法模式通过继承来实现代码复用，策略模式使用委托，委托比继承具有更大的灵活性。继承经常被错误的使用。

策略模式把不确定的行为集中到一个接口中，并在主类委托这个接口。
思考上面的订单处理例子，改为策略模式后。

1.把不确定的行为抽取为一个接口。

Public interface OrderHelper{
      public int getOrderItemPrice(OrderItem orderItem);
      public int getSpendingLimit(int customerId);
      public int saveOrder(int customerId, int total, List orderItemList);
}

2. 而把这个具体类调用这个接口的相应方法来实现具体的逻辑。

public class  Order {
   private OrderHelper orderHelpr;
   public void setOrderHelper(OrderHelper orderHelper){
    this.orderHelper = orderHelper;
  }
   public Order placeOrder(int customerId , List orderItemList){
int total = 0;
for(int i = 0; i < orderItemList.size();i++){
   OrderItem orderItem = (OrderItem)orderItemList.get(i);
   Total  += orderHelpr .getOrderItemPrice(orderItem) * orderItem.getQuantity();
}
if(total > orderHelpr .getSpendingLimit(customerId)){
  throw new BusinessException(“超出信用额度” + orderHelpr .getSpendingLimit(customerId));
}

int orderId = orderHelpr .saveOrder(customerId, total, orderItemList);
return new OrderImpl(orderId,total);

   }
}

这样Order类不再是一个抽象类，而是一个具体类。Order类委托OrderHelpher接口来完成placeOrder方法所需的基本操作。

像在这种情况下使用策略模式更具有优势，策略模式不需要继承来实现。而是通过一个委托对象来实现。OrderHelper接口无需要去继续任何指定的类。而相对来说，采用策略来实现会更复杂一些。

由此可见，模板方法模式主要应用于框架设计中,以确保基类控制处理流程的逻辑顺序（如框架的初始化）。像上面的测试基类中。框架通常需要控制反转。而在下面一些情况中，优级先考虑使用策略模式：
当需要变化的操作非常多时，采用策略模式把这些操作抽取到一个接口。
当那些基本操作的实现需要与其它类相关时，应该使用策略模式。通过委托接口把行为与实现完全分离出来（比如数据存取）。
比如订单处理的saveOrder方法，是写入数据库的。它的实现与你采用何种持久化模式相关。
当某些基本操作的实现可能需要在运行时改变时，可以通过在运行时改变委托对象来实现，而继承则不能。所以采用策略模式。

注：作者原创文章

参考文献
java与模式/阎宏编著 北京电子工业出版社 2002.10
Expert one-on-one J2EE Design And Development –Rod Johnson 2002
Design Partterns: elements of reusable object-oriented software  1994

LZ分析问题总是那么透彻..

ps:"步聚"太多,都是五笔给害的吧?

是的啊，打五笔，呵呵

Template模式确实是比较常用，在实践中，我经常使用Template模式确定工作流，而让子类去实现具体的步骤。

lZ分析得不错，特别是关于封装，以及如何控制抽象方法的粒度。不错。

嗯，很强大。
这个模式很实用，在使用时一般喜欢联合工厂来构造子类，创建一大堆的极其简单的子对象来处理业务。

大家也说说此模式的适应场景吧，hiwzg说了在工作流中使用此模式，还有其他的场景吗？

可能你会说:“把setUp方法的final修饰符去掉就可以了啊”。这样是可以的，但是去掉final修饰符后，子类是可以覆写setUp方法，而去执行一些额外的初始化。而可怕的是，父类从此失去了必须读取context文件及缓存context内容的逻辑。

此句是什么意思？
  父类从此失去了必须读取context文件及缓存context内容的逻辑。
这句话不对，还是意思表述不清楚。

楼上的，楼主的意思是说，如果把基类的setUp方法的final修饰符去掉后，那么子类要在测试前做一些其他的初始化工作时就会覆盖掉基类的setUp方法，这样的话，基类中的setUp方法就不起作用了，而基类的setUP方法的功能是读取context文件及缓存context内容的逻辑，所以父类从此失去了必须读取context文件及缓存context内容的逻辑。 除非子类在覆盖的方法中调用super.setUp(),不过这样的设计就不如勾子方法来的优雅了。。。

写的有点乱，不知道楼主是不是这样的意思？