小菜学设计模式——模板方法模式

背景

    很多时候我们总是循规蹈矩重复同一件事情,比如现在的我如果没有坚持继续学习,肯定就像一个行尸走肉一般重复的打着一样的逻辑代码,呵呵,每次完成代码之后估计还会得瑟一下,这个世界只有我能如此出色的完成这项工作,不说了,以前的我确实有点吹毛求疵、自以为是。不过,现在意识到程序员需要不断学习之后,我就把网名改为learn more, 意思是敦促自己学无止境。

    那么,对于这种样板式的重复,我们应该如何避免呢?那就是抽出重复的代码,自定义实现改变的方法!

1、使用意图

    代码复用,逻辑不发生改变!

2、生活实例

    每次进公司大门的时候,门会自动打开;每次下班离开公司大门的时候,门会自动关闭;这个打开又关闭的过程本来是每个人必须手动完成的,但是为了避免有些人不会开门,或者过于麻烦去开门,所以,自动门就这样产生了!这个小的过程中就蕴含了设计模式——模板方法模式

3、Java 例子(框架、JDK 、JEE)

    JDBC、LDAP查询或操作的时候,总有那么一些重复的代码,估计学过java的人都知道,

    首先,如果没有加载过驱动类的那么加载一个驱动;

    其次,Connection con = DriverManger.getConnection 获取一个对应数据源连接;

    然后,使用连接con来获取对应的预编译语句对象 PreparedStatement,不知道类名称写错了没有

    接着,自定义sql,对sql语句参数处理,占位符替换等,使之成为一条可以运行的语句

    继续,如果是数据库操作自然开启事务吗,否则没必要开启事务浪费资源

    最后,执行操作,关闭事务,关闭语句,关闭连接

    看到了没有,下次要执行另外一条的sql的时候还得按部就班,代码的坏味道告诉我们重复是非常容易出错的,那么如何避免这写重复呢?Spring对JDBC进行封装之后,很好的避免了重复了,使用Spring时,只要拿到事务、开启事务,在事务内部写我们的业务逻辑就好,其他内操作按照模板样式自动完成。

    自己也使用Lucene写过一个数据库表索引创建的方法,因为数据库记录比较多,首先想到的肯定是分页查询,否则一口气查询估计会内存溢出,既然是分页,那么每次分页过后的数据得马上处理,为了不影响性能,所以把整个查询放在一个数据连接里面,那么,就是数据连接和分页是一个模板,而具体对这些查询结果如何操作则是自定义扩展的地方,所以把操作方法写成一个抽象方法,供客户端实现。

4、模式类图

小菜学设计模式——模板方法模式

    父类角色:定义一个抽象类,首先声明完成某一特定任务的一些方法名称(其具体实现交给子类去完成),这些方法称为步骤。并且定义一个方法,这个方法的实现就是调用前面的那些声明过的方法,关键在于这些方法的顺序就已经在这里得到确定(子类不能更改),称之为模板方法。

   子类角色:实现了父类角色那些抽象方法(步骤),并且继承它的模板方法。因此无论如何实现步骤,它的模板是不会更改的。

   总结:

   模板方法实际上就是有步骤的完成某一件事情,而这些步骤已经在父类的方法中定义好了,把步骤中需要自定义的方法抽象出来交给子类去实现。

5、模式优点

    模板方法模式:定义一个操作中的算法的骨架,而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重新定义该算法的某些特定步骤。

    模板方法模式是通过把不变的行为搬移到超类,去除子类中的重复代码来体现他的优势。

    模板方法模式就是提供了一个很好的代码复用平台

    当不变的行为和可变的行为在方法的子类实现中混合一起时,不变的行为就会在子类中重复出现。通过模板方法把这些行为搬移到单一的地方,这样就帮助子类摆脱重复的不变行为的困扰。

    通过以上的定义,我们不一定非要用子类去实现父类,而是可以在父类中定义算法规则步骤的时候把父类的抽象方法改为调用一个抽象类的抽象方法,而这个方法具体实现则交给这个抽象类的子类去完成,这样的话,某些时候可以很好的把某些类的斧子关系分开。

6、与类似模式比较

    这个设计模式,用得非常多,也不容易产生误会,所以没什么可以去比较的


你可能感兴趣的:(模板方法模式)