首页 > > 程序设计 > Java技术 >

九：模板方法模式

2019-08-16 09:15:35来源：博客园 阅读 ()

新老客户大回馈,云服务器低至5折

九：模板方法模式

模板方法模式，一般是为了统一子类的算法实现步骤，所使用的一种手段或者说是方式。它在父类中定义一系列算法的步骤，而将具体的实现都推迟到子类。

最典型的形式就是一个接口，一个抽象父类，父类中会有一系列的抽象方法，而在子类中去一一实现这些方法。

下面LZ给举一个例子，比如我们有一个接口，里面就一个方法，是用来制造一个HTML页面，如下。

public interface PageBuilder {

    String bulidHtml();
    
}

这个接口很简单，就是直接制造一个Html页面的内容，假设我们不使用模板方法模式，直接让各个子类去直接实现这个接口，那么肯定实现的方式千奇百怪，而且步骤也乱七八糟的，这样实在不利于维护和扩展。所以我们可以使用模板方法模式，将这个过程给制定好，然后把具体的内容填充交给子类就好，这样这些子类生成的HTML页面就会非常一致。

基于这个目的，我们定义如下抽象类，去实现这个接口，并且我们定义好步骤。

复制代码 
public abstract class AbstractPageBuilder implements PageBuilder{

    private StringBuffer stringBuffer = new StringBuffer();
    
    public String bulidHtml() {
        //首先加入doctype,因为都是html页面,所以我们父类不需要推迟给子类实现,直接在父类实现
        stringBuffer.append("<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\">");
        //页面下面就是成对的一个HTML标签，我们也在父类加入,不需要给子类实现
        stringBuffer.append("<html xmlns=\"http://www.w3.org/1999/xhtml\">");
        //下面就应该是head标签里的内容了,这个我们父类做不了主了,推迟到子类实现,所以我们定义一个抽象方法,让子类必须实现
        appendHead(stringBuffer);
        //下面是body的内容了，我们父类依然无法做主，仍然推迟到子类实现
        appendBody(stringBuffer);
        //html标签的关闭
        stringBuffer.append("</html>");
        return stringBuffer.toString();
    }
    
    //第一个模板方法
    protected abstract void appendHead(StringBuffer stringBuffer);
    
    //第二个模板方法
    protected abstract void appendBody(StringBuffer stringBuffer);

}
复制代码

上面LZ已经加了注释，这下我们如果要制作一个html页面，就直接继承我们的抽象父类就可以了，而我们的子类只需要实现两个模板方法，就可以成功完成html页面的创建，下面LZ给出一个子类，我们随意制造一个html页面。

复制代码 
public class MyPageBuilder extends AbstractPageBuilder{

    @Override
    protected void appendHead(StringBuffer stringBuffer) {
        stringBuffer.append("<head><title>你好</title></head>");
    }

    @Override
    protected void appendBody(StringBuffer stringBuffer) {
        stringBuffer.append("<body><h1>你好,世界！</h1></body>");
    }
    
    public static void main(String[] args) {
        PageBuilder pageBuilder = new MyPageBuilder();
        System.out.println(pageBuilder.bulidHtml());
    }

}
复制代码

我们简单的加入一个head和body标签，然后创建测试类运行一下，就会发现，我们按照父类给的标准模板，生成了一个html页面。

这样做的方式的好处是，父类可以规范子类的创建过程，便于我们维护，而且子类也更省事，因为像doctype包括html标签都是一样的，所以子类不再需要关心这些。当然上述LZ写的有点粗糙，其实我们可以定义的更仔细一点，比如head标签里，第一个是title，然后是meta等等。但作为例子，我们还是遵循简单的原则，主要还是想给各位传达模板方法模式的思想。

 模板方法模式是所有设计模式当中，LZ觉得最无侵入性的模式，因为它的好处实在是太明显了。模板方法模式并不强制接口的实现类必须继承，所以不会对子类造成任何影响，而如果子类的实现可以配得上模板类的模板，那么就可以享受模板方法模式带来的好处。

通常情况下，模板方法模式用于定义构建某个对象的步骤与顺序，或者定义一个算法的骨架。

 我们刚才的示例明显就是构建一个String对象的过程，在这里要声明一点，对于模板方法模式，父类提供的构建步骤和顺序或者算法骨架，通常是不希望甚至是不允许子类去覆盖的，所以在某些场景中，可以直接将父类中提供骨架的方法声明为final类型。

模板方法模式还有一种使用的方式，为了给子类足够的自由度，可以提供一些方法供子类覆盖，去实现一些骨架中不是必须但却可以有自定义实现的步骤。

比如上述的例子当中，我们应该都知道，HTML页面中有一些标签是可有可无的。比如meta标签，link标签，script标签等。那么我们可以将刚才的例子细化一下，去看一下上面说的供子类覆盖的方法是什么。我们将刚才的抽象父类细化成如下形式。

复制代码 
public abstract class AbstractPageBuilder implements PageBuilder{

    private static final String DEFAULT_DOCTYPE = "<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\">";
    
    private static final String DEFAULT_XMLNS = "http://www.w3.org/1999/xhtml";
    
    private StringBuffer stringBuffer = new StringBuffer();
    
    public String bulidHtml() {
        stringBuffer.append(DEFAULT_DOCTYPE);
        stringBuffer.append("<html xmlns=\"" + DEFAULT_XMLNS + "\">");
        stringBuffer.append("<head>");
        appendTitle(stringBuffer);
        appendMeta(stringBuffer);
        appendLink(stringBuffer);
        appendScript(stringBuffer);
        stringBuffer.append("</head>");
        appendBody(stringBuffer);
        stringBuffer.append("</html>");
        return stringBuffer.toString();
    }
    
    protected void appendMeta(StringBuffer stringBuffer){
    }
    
    protected void appendLink(StringBuffer stringBuffer){
    }
    
    protected void appendScript(StringBuffer stringBuffer){
    }
    
    protected abstract void appendTitle(StringBuffer stringBuffer);
    
    protected abstract void appendBody(StringBuffer stringBuffer);

}
复制代码

可以看到，我们将head标签的生成过程更加细化了，分成四个方法，title，meta，link和script。但是这四个里面appendTitle是模板方法，子类必须实现，而其它三个则是普通的空方法。

那么上述三个方法，就是留给子类覆盖的，当然子类可以选择不覆盖，那么生成的HTML就没有meta，link和script这三种标签，如果想有的话，就可以覆盖其中任意一个，比如下面这样。

复制代码 
public class MyPageBuilder extends AbstractPageBuilder{
    
    protected void appendMeta(StringBuffer stringBuffer) {
        stringBuffer.append("<meta http-equiv=\"Content-Type\" content=\"text/html; charset=utf-8\" />");
    }

    protected void appendTitle(StringBuffer stringBuffer) {
        stringBuffer.append("<title>你好</title>");
    }

    protected void appendBody(StringBuffer stringBuffer) {
        stringBuffer.append("<body>你好，世界！</body>");
    }

    public static void main(String[] args) {
        PageBuilder pageBuilder = new MyPageBuilder();
        System.out.println(pageBuilder.bulidHtml());
    }
    
}
复制代码

 我们覆盖了appendMeta方法，所以我们就可以在head标签中生成一个meta标签。如果各位看过上章的适配器模式，其实这里和缺省适配很像，目的都是一样的，因为如果把appendMeta也写成抽象方法，那么子类就必须实现，但是meta标签又不是必须的，所以子类就有可能把appendMeta，appendLink，appendScript方法全空着了。

 所以为了不强制子类实现不必要的抽象方法，但又不剥夺子类自由选择的权利，我们在父类提供一个默认的空实现，来让子类自由选择是否要覆盖掉这些方法。

说到模板方法模式，我们JDK当中有一个类与它还有一个不得不说的故事，那就是类加载器。

DK类加载器可以大致分为三类，分别是启动类加载器，扩展类加载器，以及应用程序加载器。

这三者加载类的路径分别为如下：

 启动类加载器：JAVA_HOME/lib目录下，以及被-Xbootcalsspath参数设定的路径，不过启动类加载器加载的类是有限制的，如果JVM不认识的话，你放在这些目录下也没用。

扩展类加载器：JAVA_HOME/lib/ext目录下，以及被java.ext.dirs系统变量指定的路径。

应用程序类加载器：用户自己的类路径（classpath），这个类加载器就是我们经常使用的系统类加载器，并且JDK中的抽象类ClassLoader的默认父类加载器就是它。

在这里为什么说类加载器和模板方法模式有关呢，是因为ClassLoader类就使用了模板模式，去保证类加载过程中的唯一性。LZ先给各位看下这个类当中的模板模式的应用。

复制代码 
public abstract class ClassLoader {
    //这是一个重载方法
    public Class<?> loadClass(String name) throws ClassNotFoundException {
    return loadClass(name, false);
    }
    
    //这里就是父类算法的定义
    protected synchronized Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
    {
    Class c = findLoadedClass(name);
    if (c == null) {
        try {
        if (parent != null) {
            c = parent.loadClass(name, false);
        } else {
            c = findBootstrapClass0(name);
        }
        } catch (ClassNotFoundException e) {
            c = findClass(name);
        }
    }
    if (resolve) {
        resolveClass(c);
    }
    return c;
    }
    //这里留了一个方法给子类选择性覆盖
    protected Class<?> findClass(String name) throws ClassNotFoundException {
    throw new ClassNotFoundException(name);
    }

}
复制代码

              LZ截取了主要的部分，为了突出这三个方法。在上面LZ加了简单的注释，相信经过刚才的介绍，各位应该能看出来这是一个模板方法模式，只是它没有定义抽象方法，因为findClass这个方法，并不是必须实现的，所以JDK选择留给程序员们自己选择是否要覆盖。

              从代码上我们可以看出，在ClassLoader中定义的算法顺序是。

              1，首先看是否有已经加载好的类。

              2，如果父类加载器不为空，则首先从父类类加载器加载。

              3，如果父类加载器为空，则尝试从启动加载器加载。

              4，如果两者都失败，才尝试从findClass方法加载。

              这是JDK类加载器的双亲委派模型，即先从父类加载器加载，直到继承体系的顶层，否则才会采用当前的类加载器加载。这样做的目的刚才已经说了，是为了JVM中类的一致性。                            

              如果有读者第一次接触这方面的知识，估计会比较迷茫，下面LZ给出一个例子。各位猜测下下面程序的运行结果会是什么？

复制代码 
package com.classloader;

public class ClassLoaderTest {

    public static void main(String[] args) throws Exception {
        Class<?> clazz = ClassLoader.getSystemClassLoader().loadClass("com.classloader.ClassLoaderTest");
        Object entity = clazz.newInstance();
        System.out.println(entity instanceof ClassLoaderTest);
    }
}
复制代码

              相信各位都可以毫无疑问的猜测出来，结果应该是true，这是因为entity是ClassLoaderTest类的一个实例，instanceof关键字用来判断一个实例是否属于一个特定的类型，所以结果就是true。

              那么各位再来猜猜下面这段代码的运行结果会是什么？

复制代码 
package com.classloader;

import java.io.IOException;
import java.io.InputStream;

class MyClassLoader extends ClassLoader{
    
    public Class<?> loadClass(String name) throws ClassNotFoundException {
        String fileName = name.substring(name.lastIndexOf(".")+1) + ".class";
        InputStream is = getClass().getResourceAsStream(fileName);
        if (is == null) {
            return super.loadClass(name);
        }
        try {
            byte[] b = new byte[is.available()];
            is.read(b);
            return defineClass(name, b, 0, b.length);
        } catch (IOException e) {
            throw new ClassNotFoundException();
        }
    }
    
}

public class ClassLoaderTest {

    public static void main(String[] args) throws InstantiationException, IllegalAccessException, ClassNotFoundException {
        ClassLoader classLoader = new MyClassLoader();
        Class<?> clazz = classLoader.loadClass("com.classloader.ClassLoaderTest");
        Object entity = clazz.newInstance();
        System.out.println(entity instanceof ClassLoaderTest);
    }
    
}
复制代码

              对于类加载器比较熟悉的读者们可能觉得这个结果并不出乎意料，可是或许还是有人会比较意外，为什么结果会是false呢？

              这是因为如果没有按照ClassLoader中提供的骨架算法去加载类的话，可能会造成JVM中有两个一模一样的类信息，他们是来自一个类文件，但却不是一个加载器加载的，所以这两个类不相等。

              这也是类加载器为何要使用模板模式给我们定义好查找的算法，是为了保证我们加载的每一个类在虚拟机当中都有且仅有一个。

              不过你可能会想，既然如此，为何不把loadClass方法写成final类型的，这样不是更安全吗？

              这是因为有的时候我们希望JVM当中每一个类有且仅有一个，但有的时候我们希望有两个，甚至N个，就比如我们的tomcat，你可以想象下，你每一个项目假设都有com.xxx.xxxx.BaseDao等等，如果这些类都是一个的话，你的tomcat还能同时启动多个WEB服务吗？虽说tomcat也是遵循的双亲委派模型，但是从此也可以看出来，我们并不是在所有时候都希望同一个全限定名的类在整个JVM里面只有一个。

              这里提到类加载器，是为了给模板方法一个现有的现实中的例子，以便于有些看多了自己制造的例子的读者可以换个口味，如果有机会，LZ会在这个系列完结以后，专门开一个系列来和各位分享学习虚拟机过程中的感悟，本次不再过多介绍类加载器的相关内容


原文链接:https://www.cnblogs.com/2019lgg/p/11089652.html
如有疑问请与原作者联系

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有

上一篇：一篇文章帮你彻底搞清楚“I/O多路复用”和“异步I/O”的前世今生

下一篇：springmvc的执行流程

相关文章

IDC资讯： 主机资讯 注册资讯 托管资讯 vps资讯 网站建设

网站运营： 建站经验 策划盈利 搜索优化 网站推广 免费资源

网站联盟： 联盟新闻 联盟介绍 联盟点评 网赚技巧

行业资讯： 搜索引擎 网络游戏 电子商务 广告传媒

网络编程： Asp.Net编程 Asp编程 Php编程 Xml编程 Access Mssql Mysql 其它

服务器技术： Web服务器 Ftp服务器 Mail服务器 Dns服务器 安全防护

软件技巧： 其它软件 Word Excel Powerpoint Ghost Vista QQ空间 QQ FlashGet 迅雷

网页制作： FrontPages Dreamweaver Javascript css photoshop fireworks Flash

程序设计： Java技术 C/C++ VB delphi

网络知识： 网络协议 网络安全 网络管理 组网方案 Cisco技术

操作系统： Win2000 WinXP Win2003 Mac OS Linux FreeBSD

热门词条
最新资讯
热门关注
热门标签