九:模板方法模式

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的执行流程