模板方法

模板方法模式在一个方法中定义一个算法的骨架，而将一些步骤的实现延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中某些步骤的具体实现。

例子

现在我家里有一台铃木的小车锋驭和一台铃木的摩托车风暴1000，我要想把这两种类型的车都先跑起来再停下来，有一些步骤，并且这些步骤是有先后顺序的，那就是：

1. 打开车门
2. 启动发动机
3. 挂档
4. 走起
5. 刹车
6. 停车

OO设计原则之一就是分离可变和不变的部分并把可变的部分封装起来，我们来看一下以上两种类型的车，哪些步骤的实现是一样的，哪些是可变的。我们把不变的部分提取出来并放到超类中让所有子类共享其行为，同时我们把可变部分的具体实现延迟到子类中，让子类来自行决定如何实现。

1. 打开车门（摩托车没有车门，可变部分）

2. 启动发动机（不变部分）

3. 挂档（汽车用手挂档，摩托车用脚挂档，可变部分）

4. 走起（不变部分）

5. 刹车（汽车用脚刹车，摩托车用手刹车，可变部分）

6. 停车（不变部分）

当然以上分离可变及不变部分纯属个人见解，个位看官见仁见智。

如果运用设计模式的方法论，我们应该采用哪种模式来很好地满足我们的需求？

在这种应用场景下我建议使用模板方法模式。

基于以上UML类图我需要说明几点模板方法的设计意图：

DriveTemplate是一个抽象类，我们可以把一些可变的部分封装为抽象方法让子类去做具体实现。

DriveTemplate中的drive方法是final的，这样是因为我们不希望子类去覆盖这个方法，因为这个方法中定义了算法的步骤，我们不希望子类改变算法的结构。

所有的步骤方法都是protected的访问修饰符，因为我们希望具体算法的实现只有子类可以访问，对外是不开放的。

代码

模板抽象类

package com.singland.dp.template;
public abstract class DriveTemplate {
    public final void drive() {
        openDoor();
        startEngine();
        gear();
        go();
        brake();
        stop();
    }

    protected abstract void openDoor();

    protected void startEngine() {
        System.out.println("engine started !");
    }

    protected abstract void gear();

    protected void go() {
        System.out.println("running...");
    }

    protected abstract void brake();

    protected void stop() {
        System.out.println("stopped !");
    }
}

小车锋驭的实现

package com.singland.dp.template;

public class SuzukiScross extends DriveTemplate {

    @Override
    protected void openDoor() {
        System.out.println("keyless entry");
    }

    @Override
    protected void gear() {
        System.out.println("gear with hand");
    }

    @Override
    protected void brake() {
        System.out.println("brake with foot");
    }
}

摩托车风暴1000的具体实现

package com.singland.dp.template;

public class SuzukiStrom1000 extends DriveTemplate {

    @Override
    protected void openDoor() {
        System.out.println("no door actually");
    }

    @Override
    protected void gear() {
        System.out.println("gear with foot");
    }

    @Override
    protected void brake() {
        System.out.println("brake with hand");
    }
}

客户端的测试代码就很简单了

package com.singland.dp.template;

import org.junit.Test;

public class MyTest {

    @Test
    public void test() {
//        DriveTemplate template = new SuzukiStrom1000();
        DriveTemplate template = new SuzukiScross();
        template.drive();
    }
}

刚才说到模板方法模式的设计意图的时候，我们提到了第2点，我们不希望子类改变算法的结构或顺序，但是在某种场景中，我们希望子类能有一些自主权，虽然它们不能覆盖drive方法，但是我们依然希望子类可以自己决定一些东西，那么模板方法模式能否满足这一需求呢？

答案是肯定的，我们来设想这种场景，当我们在开锋驭的时候，我希望可以打开车子的MP3功能来听歌，但是骑摩托车的时候则不需要。

这样我们的UML类图就需要做一点点小改动：

从类图可以看出，我们在超类中定义了一个music的方法，但是它并不是一个抽象方法，这样子类可以自己决定是否覆盖该方法，该方法返回值是一个布尔值的标志位，默认为false. 子类SuzukiScross覆盖了该方法但是SuzukiStorm1000则没有，我们再来看看具体的实现：

模板方法类

package com.singland.dp.template;

public abstract class DriveTemplate {

    public final void drive() {
        openDoor();
        startEngine();
        gear();
        go();
        if (music()) {
            mp3();
        }
        brake();
        stop();
    }

    protected abstract void openDoor();

    protected void startEngine() {
        System.out.println("engine started !");
    }

    protected abstract void gear();

    protected void go() {
        System.out.println("running...");
    }

    private void mp3() {
        System.out.println("music is good");
    }

    protected boolean music() {
        return false;
    }

    protected abstract void brake();

    protected void stop() {
        System.out.println("stopped !");
    }
}

锋驭的实现：

package com.singland.dp.template;

public class SuzukiScross extends DriveTemplate {

    @Override
    protected void openDoor() {
        System.out.println("keyless entry");
    }

    @Override
    protected void gear() {
        System.out.println("gear with hand");
    }

    @Override
    protected void brake() {
        System.out.println("brake with foot");
    }

    @Override
    protected boolean music() {
        return true;
    }
}

总结

写到这里，我来个简单的总结吧。本质上来说，模板方法设计模式是一个比较容易而且很好理解的模式，在
使用这种模式的时候我们要注意几点：

保护抽象类中定义算法顺序的方法不被子类修改。

分离可变及不可变部分，让子类自己决定可变部分的实现。

让算法的具体实现对子类开放，对其他类关闭。

JDBC使用模板方法

传统的jdbc存在的缺陷和不足

首先我们来一下以往我们使用jdbc进行数据库操作的代码是什么样的？

public class UpdateDateBase {

   static final String JDBC_DRIVER = "com.mysql.jdbc.Driver";  
   static final String DB_URL = "jdbc:mysql://localhost/jdbc_db";
   static final String USER = "root";
   static final String PASS = "123456";

   public static void main(String[] args) {
   Connection conn = null;
   Statement stmt = null;
   try{

      Class.forName("com.mysql.jdbc.Driver");
      conn = DriverManager.getConnection(DB_URL, USER, PASS);
      stmt = conn.createStatement();
      String sql = "UPDATE student " +"SET age = 22 WHERE id in (100, 101)";
      stmt.executeUpdate(sql);
      sql = "SELECT id, first, last, age FROM student";
      ResultSet rs = stmt.executeQuery(sql);
      while(rs.next()){
         int id  = rs.getInt("id");
         int age = rs.getInt("age");
         String first = rs.getString("first");
         String last = rs.getString("last");
      }
      rs.close();
   }catch(SQLException se){
      se.printStackTrace();
   }catch(Exception e){
      e.printStackTrace();
   }finally{
      try{
         if(stmt!=null)
            conn.close();
      }catch(SQLException se){
      }
      try{
         if(conn!=null)
            conn.close();
      }catch(SQLException se){
         se.printStackTrace();
      }
   }
}
}

这里只是做了一个简单的操作，对数据进行更新，再查询显示出来，可以看到这么一大长串，假如我们再进行一个删除操作，还得把这些步骤再来一遍，天呐，头都要大了，写代码最烦的就是写重复烦躁的代码。这就是传统jdbc的编码，存在以下不足：

1：对外暴露的细节太多

比如把数据库名、密码、用户名、Ip等都暴露出来，万一代码落入到还有不轨企图的人手里，只要看一下你的jdbc，它就可以得到你数据库的所有信息。其实安全这一点对企业来说非常重要，如果没有参加工作的童鞋可能还意识不到这一点

2：冗余

重复的代码太多，都是做一些重复机械的操作，首先是获取驱动、得到连接、生成Statement,再编译sql，执行，取结果遍历，最后还得再关闭结果集、关闭连接、关闭statement,防止抛异常,还得考虑事务，万一出错还得考虑回滚等等。

3：代码编写比较繁复

这其中万一有一个步骤出错了，比如忘记关闭数据库连接池了，这样就会发生很多莫名奇妙的问题，比如再次更新数据库发现没有变化，这就是没有关闭连接池导致的。这种细节性操作很容易酿造大的事情，程序员需要关注的细节过多

4：向方法中的sql语句传参数麻烦

因为sql语句的where条件不一定，可能多也可能少，占位符需要和参数一一对应，这其中万一出错了，就会导致无法操作数据库

JDBCTemplate源码分析

关于JDBCTemplate：它是这样一个类，它把我们对数据库的操作jdbc代码高度封装，并且采用了模板方法的设计思想，将其抽象成回调接口和工具类调用的方法，把特定的步骤通过工具类来组装，这样可以实现固定步骤的高度可重用。只需要编写一次，我们就可以进行重复利用起来。
JDBCTemplate的继承关系

上面是它的继承关闭图，它继承自抽象类JdbcAccessor和JdbcOperations接口。其中JdbcAccessor设定了处理数据源DataSoucre和sql的异常检验操作，而JdbcOperations则负责具体的查询query、update操作、批处理batchUpdate等，同时继承自两个父类，让JDBCTemplate具有操作数据库和处理数据源、获取异常的能力。
3:JDBCTemplate的成员变量

这些成员变量是它本身的，我来翻译一下它的含义：

private static final String RETURN_RESULT_SET_PREFIX = "#result-set-";//前缀
private static final String RETURN_UPDATE_COUNT_PREFIX = "#update-count-";//计数前缀
private NativeJdbcExtractor nativeJdbcExtractor;//本地JDBC执行器
private boolean ignoreWarnings = true;//是否忽略警告
private int fetchSize = 0;//查询到的大小
private int maxRows = 0;//最大行数
private int queryTimeout = 0;//查询时间
private boolean skipResultsProcessing = false;//是否跳过结果处理
private boolean skipUndeclaredResults = false;//是否跳过非公共结果
private boolean resultsMapCaseInsensitive = false;//Map结果的是否大小写敏感

但是因为它继承了一个抽象类和接口，它同样享有JdbcAccesor的成员变量，可以看到DataSoucre已经注入了，但它是private的，虽然可以继承，但是不能使用，不过可以引用JdbcAccesor中的setter方法进行设值

父类中的这些很简单，基本上可以很直接的看出来，它们分别是日志记录器、数据源、sql异常转换器、是否懒加载，这些成员变量是全局的，也就是说它们存在着线程安全的问题，为此Spring还专门采用了单例加锁的设计模式来获取exceptionTranslator对象，以下是源码：

可以看到它使用了synchronize关键字，这个锁是方法级别上的，获取exceptionTranslator对象，根据dataSoure是否为空来判断实现的不同子类SQLErrorCodeSQLExceptionTranslator（需要DataSource）和SQLStateSQLExceptionTranslator（不需要DataSource）;

jdbcTemplate的构造方法

可以看到它有三个构造方法，标记为①的是个空构造方法，这个不用多说了。第二个它的话它引用了JdbcAccesor注入了DataSource，然后调用了父类中的属性设置后的方法this.arterPropertiesSet()，我们来看看它的源码：

可以看到这是和懒加载有关的一个方法，没有懒加载，就会调用本类中的方法调用2.3中讲的方法获取异常转换器中
第三个构造方法，它在第二个的基础上增加了设置LazyInit的字段，设置它是否支持懒加载，关于懒加载：它是一种节省资源提高效率的做法，数据只有在真正用到的时候才去加载它。

jdbcTemplate执行sql原理

我们来看一下它执行sql的方法exexute的源码：

首先它是一个日志记录，级别在debug，然后方法中声明了一个类，这个类继承了StatementCallback接口和sqlProvider接口，这个接口只有一个方法，主要负责的就是用Statement这个对象执行sql。

最后再把这个接口传入execute重载方法，我们来看一下它对接口作了哪些处理：

我们来分析一下这段源码，它主要是获取connection对象，再通过对象赋值，通过本地jdbc提取器再次获取，然后再通过该对象创建Statement，再进行设值，再通过对象赋值给另一个对象，至于Spring中为什么经常出现这种代码-指的是对象赋值转接，这里可以理解为对象的一个复制过程，然后再做重新的处理。再调用接口中的doInstatement方法执行sql获取结果，又再次出现把对象转接过去，对结果进行赋值，然后在catch代码块中关闭Statement和释放连接，再抛出异常，在finally块中确保关闭Statement和Connection.

jdbcTemplate的update方法源码分析

我们看到这就是它的update方法，首先是一个断言机制：sql必须不为null，关于断言就是一种假设机制，假设程序运行到这里对参数进行校验，如果不满足的话，将会抛出AssertionError异常。然后是日志记录sql，接着是一个方法内部类，这里又用到实现了回调接口StatementCallback，它的主要方法是doInstatement，调用jdbc中的的executeUpdate方法执行完返回一个int类型的值，最后返回这个值，然后再次调用execute方法，把方法内部的实现类传进去，和刚才的一样，做了必要的关闭Statement和connection操作，还有一些异常的抛出操作和警告等的处理

jdbcTemplate的批量更新方法源码

批量更新batchupdate可以看到它传入的是一个sql的数组，那么我们在调用的时候需要传入肯定是一个sql的数组集合。然后和上面的一样断言、日志开启，再在方法内部新建一个类实现Statement回调接口，再其中先判断是否支持批量查询，再进行循环遍历，通过appendSql方法拼接sql语句，再用statement批量更新，最后返回影响的行数。
上面的源码是进行一场判断的处理，抛出具体哪个sql异常，else的部分是指不支持批量查询的情况，它就会抛出异常Invaild batch sql Statement+具体的sql语句，最后再返回影响的行数

jdbcTemplate的使用方法

首先在application.xml中配置jdbcTemplate Bean：

这里可以看到配置的过程中引用了DataSource数据源，这里的主要原因是我在2.3中讲到的它有DataSource这个成员变量，然后我们来看一下DataSource配置了哪些东西

这里的DateSource主要是数据库的配置，数据库也就是我们数据的来源
不过使用这种方式的话，记得要在Spring的配置文件中写上，location是资源文件的路径：

如果其他配置好的话，接下来我们看看如何具体使用它：

jdbcTemplate肯定是在Dao层了，我们用@AutoWired注入这个对象，然后可以调用它的方法执行sql就行了。其他的比如关闭操作、异常处理、回滚等操作压根不用操心，这个类已经帮我们处理好了一切，怎么样，够简单吧。
ps:其他的使用方法同理。只需要用这个jdbctemplate调用方法就可以了。
四：总结
本篇博客主要讲解了原始jdbc的不足和jdbctemplate采用模板设计模式对其进行了高度封装的过程，并且分析它的源码，和使用过程，源码只要理解了就行，用的时候可以直接调用，其中它本身大量使用了回调机制，在方法内部声明一个类实现回调接口，调用接口中的方法进行处理。主要的重要部分是源码的剖析，理解它的回调接口，然后理解模板设计方法带给我们的好处，在项目中多多使用它，毕竟封装可是面向对象的三大特性之一。

模板方法

模板方法

例子

模板抽象类

总结

JDBC使用模板方法

传统的jdbc存在的缺陷和不足

1：对外暴露的细节太多

2：冗余

3：代码编写比较繁复

4： 向方法中的sql语句传参数麻烦

JDBCTemplate源码分析

jdbcTemplate的构造方法

jdbcTemplate执行sql原理

jdbcTemplate的update方法源码分析

jdbcTemplate的批量更新方法源码

jdbcTemplate的使用方法

首先在application.xml中配置jdbcTemplate Bean：

4：向方法中的sql语句传参数麻烦