模板方法模式是我工作中用到最多的模式，这个模式的类图比较简单，而且思路也比较简单，只要有重复的工作，加以抽象，都可以使用模板方法。

模板方法的前提

        道理很好讲，但是很多人依旧会问，为什么他的编码环境却没有这样的使用情况。

       设计模式是基于面向对象的套路，所以脱离不了抽象这个概念，很多情况之所以没办法去模式化主要是因为无法抽象。

       我们做一件事情，都是分步骤的，例如去煮咖啡，先准备咖啡，然后水加热，放咖啡豆，结束后装入容器。针对这件事情，并不能有什么想法，抽象的基础是找共同点，起码是两个事物之间的影响的结果，如果还有一件事情是煮茶叶，那么过程就是准备茶叶，然后水加热，放茶叶，结束后装入容器。那么明显可以抽象煮东西的这个过程。准备材料，水加热，放材料，结束后装入容器。但是另外一件事情是砍柴，那么这样貌似就不好找细节上的共同点了。很多情况下，没有模式主要是场景的问题，编码就写一个场景，共同点不好找，纯粹靠想象去抽象，可能模式是用上了，但是没有普及性。效果基本和没有模式差不多。

类图

     模板方法模式的主要的思想就是定制一个流程，每个实现类都去遵循这个流程。这个流程是需要通过具体场景去抽象的。

常见案例

    最开始学习web编程的时候都会接触HttpServlet，写自己的servlet的时候，要继承这个类，去重写doget和dopost。这里用的就是模板方法模式。具体的流程就在service方法中。

  protected void service(HttpServletRequest req, HttpServletResponse resp)     throws ServletException, IOException   {     String method = req.getMethod();     //get     if (method.equals("GET"))     {       long lastModified = getLastModified(req);       if (lastModified == -1L)       {         doGet(req, resp);       }       else       {         long ifModifiedSince;         try         {           ifModifiedSince = req.getDateHeader("If-Modified-Since");         }         catch (IllegalArgumentException iae)         {           long ifModifiedSince;           ifModifiedSince = -1L;         }         if (ifModifiedSince < lastModified / 1000L * 1000L)         {           maybeSetLastModified(resp, lastModified);           doGet(req, resp);         }         else         {           resp.setStatus(304);         }       }     }     //head     else if (method.equals("HEAD"))     {       long lastModified = getLastModified(req);       maybeSetLastModified(resp, lastModified);       doHead(req, resp);     }     //post     else if (method.equals("POST"))     {       doPost(req, resp);     }     //put     else if (method.equals("PUT"))     {       doPut(req, resp);     }     //delete     else if (method.equals("DELETE"))     {       doDelete(req, resp);     }     //options     else if (method.equals("OPTIONS"))     {       doOptions(req, resp);     }     //trace     else if (method.equals("TRACE"))     {       doTrace(req, resp);     }     else     {       String errMsg = lStrings.getString("http.method_not_implemented");       Object[] errArgs = new Object[1];       errArgs[0] = method;       errMsg = MessageFormat.format(errMsg, errArgs);              resp.sendError(501, errMsg);     }   }

    在service中对http支持的7中方式都做了处理，剩下的就是每个servlet根据自己的情况覆写doGet，doHead，doPost，doPut，doDelete，doOptions，doTrace。具体的业务也写在具体的方法里，具体是调用的是哪种请求方法由service方法中确认。

思想类似的产物

    java的jdbc的操作都是获取连接，创建statment或者preparestatement，然后执行sql，然后关闭resultset（如果有的话），关闭statement，然后关闭连接。具体和业务相关的其实就是sql，剩下的都是流程化的过程。spring jdbc template就是模板化了这些过程，不同的是，他使用了组合的方式去调用而不是继承，严格意义上不是标准的模板方法，只能说是思想类似。

实战场景

工作中遇到一个场景就是用模板方法来做一个try catch的异常模板。

场景

      最开始写的代码出现一个问题，就是有异常没有处理的话，逻辑都被中断了。因此需要加入异常处理。要这样改的地方还有很多。

代码模板

 public class Template {  	public static void main(String[] args) { 		 		new ExceptionTemplate(){ 			@Override 			protected void toDo() { 				//流程 				System.out.println("over"); 			} 		}.doWork();  	}  } //模板类 abstract class ExceptionTemplate{ 	public final void doWork(){ 		 try{ 			 toDo(); 		 }catch(Exception e){ 			 //异常处理方式 		 } 		 	} 	protected  void toDo(){} }

好处

       每个地方的改动都是有限的，都是new一个匿名内部类，调用一下方法，原来的写的代码都移动到抽象类方法中，提交的代码的变动相对比较少，而且不容易出错，逻辑都在模板里，只要想好一个就可以了。