彻底搞懂访问者模式的静态、动态和伪动态分派

本文节选自《设计模式就该这样学》

1 使用访问者模式实现KPI考核的场景

每到年底,管理层就要开始评定员工一年的工作绩效,员工分为工程师和经理;管理层有CEO和CTO。那么CTO关注工程师的代码量、经理的新产品数量;CEO关注工程师的KPI、经理的KPI及新产品数量。
由于CEO和CTO对于不同的员工的关注点是不一样的,这就需要对不同的员工类型进行不同的处理。此时,访问者模式可以派上用场了,来看代码。


//员工基类
public abstract class Employee {

    public String name;
    public int kpi;//员工KPI

    public Employee(String name) {
        this.name = name;
        kpi = new Random().nextInt(10);
    }
    //核心方法,接受访问者的访问
    public abstract void accept(IVisitor visitor);
}

Employee类定义了员工基本信息及一个accept()方法,accept()方法表示接受访问者的访问,由具体的子类来实现。访问者是一个接口,传入不同的实现类,可访问不同的数据。下面看工程师Engineer类的代码。


//工程师
public class Engineer extends Employee {

    public Engineer(String name) {
        super(name);
    }

    @Override
    public void accept(IVisitor visitor) {
        visitor.visit(this);
    }
    //工程师一年的代码量
    public int getCodeLines() {
        return new Random().nextInt(10 * 10000);
    }
}

经理Manager类的代码如下。


//经理
public class Manager extends Employee {

    public Manager(String name) {
        super(name);
    }

    @Override
    public void accept(IVisitor visitor) {
        visitor.visit(this);
    }
    //一年做的新产品数量
    public int getProducts() {
        return new Random().nextInt(10);
    }
}

工程师被考核的是代码量,经理被考核的是新产品数量,二者的职责不一样。也正是因为有这样的差异性,才使得访问模式能够在这个场景下发挥作用。Employee、Engineer、Manager 3个类型相当于数据结构,这些类型相对稳定,不会发生变化。
将这些员工添加到一个业务报表类中,公司高层可以通过该报表类的showReport()方法查看所有员工的业绩,代码如下。


//员工业务报表类
public class BusinessReport {

    private List<Employee> employees = new LinkedList<Employee>();

    public BusinessReport() {
        employees.add(new Manager("经理-A"));
        employees.add(new Engineer("工程师-A"));
        employees.add(new Engineer("工程师-B"));
        employees.add(new Engineer("工程师-C"));
        employees.add(new Manager("经理-B"));
        employees.add(new Engineer("工程师-D"));
    }

    /**
     * 为访问者展示报表
     * @param visitor 公司高层,如CEO、CTO
     */
    public void showReport(IVisitor visitor) {
        for (Employee employee : employees) {
            employee.accept(visitor);
        }
    }
}

下面来看访问者类型的定义,访问者声明了两个visit()方法,分别对工程师和经理访问,代码如下。


public interface IVisitor {

    //访问工程师类型
    void visit(Engineer engineer);

    //访问经理类型
    void visit(Manager manager);
}

上面代码定义了一个IVisitor接口,该接口有两个visit()方法,参数分别是Engineer和Manager,也就是说对于Engineer和Manager的访问会调用两个不同的方法,以此达到差异化处理的目的。这两个访问者具体的实现类为CEOVisitor类和CTOVisitor类。首先来看CEOVisitor类的代码。


//CEO访问者
public class CEOVisitor implements IVisitor {

    public void visit(Engineer engineer) {
        System.out.println("工程师: " + engineer.name + ", KPI: " + engineer.kpi);
    }

    public void visit(Manager manager) {
        System.out.println("经理: " + manager.name + ", KPI: " + manager.kpi +
                ", 新产品数量: " + manager.getProducts());
    }
}

在CEO的访问者中,CEO关注工程师的KPI、经理的KPI和新产品数量,通过两个visit()方法分别进行处理。如果不使用访问者模式,只通过一个visit()方法进行处理,则需要在这个visit()方法中进行判断,然后分别处理,代码如下。


public class ReportUtil {
    public void visit(Employee employee) {
        if (employee instanceof Manager) {
            Manager manager = (Manager) employee;
            System.out.println("经理: " + manager.name + ", KPI: " + manager.kpi +
                    ", 新产品数量: " + manager.getProducts());
        } else if (employee instanceof Engineer) {
            Engineer engineer = (Engineer) employee;
            System.out.println("工程师: " + engineer.name + ", KPI: " + engineer.kpi);
        }
    }
}

这就导致了if…else逻辑的嵌套及类型的强制转换,难以扩展和维护,当类型较多时,这个ReportUtil就会很复杂。而使用访问者模式,通过同一个函数对不同的元素类型进行相应处理,使结构更加清晰、灵活性更高。然后添加一个CTO的访问者类CTOVisitor。


public class CTOVisitor implements IVisitor {

    public void visit(Engineer engineer) {
        System.out.println("工程师: " + engineer.name + ", 代码行数: " + engineer.getCodeLines());
    }

    public void visit(Manager manager) {
        System.out.println("经理: " + manager.name + ", 产品数量: " + manager.getProducts());
    }
}

重载的visit()方法会对元素进行不同的操作,而通过注入不同的访问者又可以替换掉访问者的具体实现,使得对元素的操作变得更灵活,可扩展性更高,同时,消除了类型转换、if…else等“丑陋”的代码。
客户端测试代码如下。


public static void main(String[] args) {
        //构建报表
        BusinessReport report = new BusinessReport();
        System.out.println("=========== CEO看报表 ===========");
        report.showReport(new CEOVisitor());
        System.out.println("=========== CTO看报表 ===========");
        report.showReport(new CTOVisitor());
}

运行结果如下图所示。

file

在上述案例中,Employee扮演了Element角色,Engineer和Manager都是 ConcreteElement,CEOVisitor和CTOVisitor都是具体的Visitor对象,BusinessReport就是ObjectStructure。
访问者模式最大的优点就是增加访问者非常容易,从代码中可以看到,如果要增加一个访问者,则只要新实现一个访问者接口的类,从而达到数据对象与数据操作相分离的效果。如果不使用访问者模式,而又不想对不同的元素进行不同的操作,则必定需要使用if…else和类型转换,这使得代码难以升级维护。
我们要根据具体情况来评估是否适合使用访问者模式。例如,对象结构是否足够稳定,是否需要经常定义新的操作,使用访问者模式是否能优化代码,而不使代码变得更复杂。

2 从静态分派到动态分派

变量被声明时的类型叫作变量的静态类型(Static Type),有些人又把静态类型叫作明显类型(Apparent Type);而变量所引用的对象的真实类型又叫作变量的实际类型(Actual Type)。比如:


List list = null;
list = new ArrayList();

上面代码声明了一个变量list,它的静态类型(也叫作明显类型)是List,而它的实际类型是ArrayList。根据对象的类型对方法进行的选择,就是分派(Dispatch)。分派又分为两种,即静态分派和动态分派。

2.1 静态分派

静态分派(Static Dispatch)就是按照变量的静态类型进行分派,从而确定方法的执行版本,静态分派在编译期就可以确定方法的版本。而静态分派最典型的应用就是方法重载,来看下面的代码。


public class Main {
    public void test(String string){
        System.out.println("string");
    }

    public void test(Integer integer){
        System.out.println("integer");
    }

    public static void main(String[] args) {
        String string = "1";
        Integer integer = 1;
        Main main = new Main();
        main.test(integer);
        main.test(string);
    }
}

在静态分派判断的时候,根据多个判断依据(即参数类型和个数)判断出方法的版本,这就是多分派的概念,因为我们有一个以上的考量标准,所以Java是静态多分派的语言。

2.2 动态分派

对于动态分派,与静态分派相反,它不是在编译期确定的方法版本,而是在运行时才能确定的。而动态分派最典型的应用就是多态的特性。举个例子,来看下面的代码。


interface Person{
    void test();
}
class Man implements Person{
    public void test(){
        System.out.println("男人");
    }
}
class Woman implements Person{
    public void test(){
        System.out.println("女人");
    }
}
public class Main {
    public static void main(String[] args) {
        Person man = new Man();
        Person woman = new Woman();
        man.test();
        woman.test();
    }
}

这段代码的输出结果为依次打印男人和女人,然而这里的test()方法版本,无法根据Man和Woman的静态类型判断,他们的静态类型都是Person接口,根本无从判断。
显然,产生这样的输出结果,就是因为test()方法的版本是在运行时判断的,这就是动态分派。
动态分派判断的方法是在运行时获取Man和Woman的实际引用类型,再确定方法的版本,而由于此时判断的依据只是实际引用类型,只有一个判断依据,所以这就是单分派的概念,这时考量标准只有一个,即变量的实际引用类型。相应地,这说明Java是动态单分派的语言。

3 访问者模式中的伪动态分派

通过前面的分析,我们知道Java是静态多分派、动态单分派的语言。Java底层不支持动态双分派。但是通过使用设计模式,也可以在Java里实现伪动态双分派。在访问者模式中使用的就是伪动态双分派。所谓动态双分派就是在运行时依据两个实际类型去判断一个方法的运行行为,而访问者模式实现的手段是进行两次动态单分派来达到这个效果。
还是回到前面的KPI考核业务场景中,BusinessReport类中的showReport()方法的代码如下。


public void showReport(IVisitor visitor) {
        for (Employee employee : employees) {
            employee.accept(visitor);
        }
}

这里依据Employee和IVisitor两个实际类型决定了showReport()方法的执行结果,从而决定了accept()方法的动作。
accept()方法的调用过程分析如下。

(1)当调用accept()方法时,根据Employee的实际类型决定是调用Engineer还是Manager的accept()方法。

(2)这时accept()方法的版本已经确定,假如是Engineer,则它的accept()方法调用下面这行代码。


    public void accept(IVisitor visitor) {
        visitor.visit(this);
    }
		

此时的this是Engineer类型,因此对应的是IVisitor接口的visit(Engineer engineer)方法,此时需要再根据访问者的实际类型确定visit()方法的版本,如此一来,就完成了动态双分派的过程。
以上过程通过两次动态双分派,第一次对accept()方法进行动态分派,第二次对访问者的visit()方法进行动态分派,从而达到根据两个实际类型确定一个方法的行为的效果。
而原本的做法通常是传入一个接口,直接使用该接口的方法,此为动态单分派,就像策略模式一样。在这里,showReport()方法传入的访问者接口并不是直接调用自己的visit()方法,而是通过Employee的实际类型先动态分派一次,然后在分派后确定的方法版本里进行自己的动态分派。

注:这里确定accept(IVisitor visitor)方法是由静态分派决定的,所以这个并不在此次动态双分派的范畴内,而且静态分派是在编译期完成的,所以accept(IVisitor visitor)方法的静态分派与访问者模式的动态双分派并没有任何关系。动态双分派说到底还是动态分派,是在运行时发生的,它与静态分派有着本质上的区别,不可以说一次动态分派加一次静态分派就是动态双分派,而且访问者模式的双分派本身也是另有所指。

而this的类型不是动态分派确定的,把它写在哪个类中,它的静态类型就是哪个类,这是在编译期就确定的,不确定的是它的实际类型,请小伙伴们也要区分开来。

4 访问者模式在JDK源码中的应用

首先来看JDK的NIO模块下的FileVisitor接口,它提供了递归遍历文件树的支持。这个接口上的方法表示了遍历过程中的关键过程,允许在文件被访问、目录将被访问、目录已被访问、发生错误等过程中进行控制。换句话说,这个接口在文件被访问前、访问中和访问后,以及产生错误的时候都有相应的钩子程序进行处理。
调用FileVisitor中的方法,会返回访问结果的FileVisitResult对象值,用于决定当前操作完成后接下来该如何处理。FileVisitResult的标准返回值存放在FileVisitResult枚举类型中,代码如下。


public interface FileVisitor<T> {

    FileVisitResult preVisitDirectory(T dir, BasicFileAttributes attrs)
        throws IOException;

    FileVisitResult visitFile(T file, BasicFileAttributes attrs)
        throws IOException;

    FileVisitResult visitFileFailed(T file, IOException exc)
        throws IOException;

    FileVisitResult postVisitDirectory(T dir, IOException exc)
        throws IOException;
}

(1)FileVisitResult.CONTINUE:这个访问结果表示当前的遍历过程将会继续。

(2)FileVisitResult.SKIP_SIBLINGS:这个访问结果表示当前的遍历过程将会继续,但是要忽略当前文件/目录的兄弟节点。

(3)FileVisitResult.SKIP_SUBTREE:这个访问结果表示当前的遍历过程将会继续,但是要忽略当前目录下的所有节点。

(4)FileVisitResult.TERMINATE:这个访问结果表示当前的遍历过程将会停止。

通过访问者去遍历文件树会比较方便,比如查找文件夹内符合某个条件的文件或者某一天内所创建的文件,这个类中都提供了相对应的方法。它的实现其实也非常简单,代码如下。


public class SimpleFileVisitor<T> implements FileVisitor<T> {
    protected SimpleFileVisitor() {
    }

    @Override
    public FileVisitResult preVisitDirectory(T dir, BasicFileAttributes attrs)
        throws IOException
    {
        Objects.requireNonNull(dir);
        Objects.requireNonNull(attrs);
        return FileVisitResult.CONTINUE;
    }

    @Override
    public FileVisitResult visitFile(T file, BasicFileAttributes attrs)
        throws IOException
    {
        Objects.requireNonNull(file);
        Objects.requireNonNull(attrs);
        return FileVisitResult.CONTINUE;
    }

    @Override
    public FileVisitResult visitFileFailed(T file, IOException exc)
        throws IOException
    {
        Objects.requireNonNull(file);
        throw exc;
    }

    @Override
    public FileVisitResult postVisitDirectory(T dir, IOException exc)
        throws IOException
    {
        Objects.requireNonNull(dir);
        if (exc != null)
            throw exc;
        return FileVisitResult.CONTINUE;
    }
}

5 访问者模式在Spring源码中的应用

再来看访问者模式在Spring中的应用,Spring IoC中有个BeanDefinitionVisitor类,其中有一个visitBeanDefinition()方法,源码如下。



public class BeanDefinitionVisitor {

	@Nullable
	private StringValueResolver valueResolver;


	public BeanDefinitionVisitor(StringValueResolver valueResolver) {
		Assert.notNull(valueResolver, "StringValueResolver must not be null");
		this.valueResolver = valueResolver;
	}

	protected BeanDefinitionVisitor() {
	}

	public void visitBeanDefinition(BeanDefinition beanDefinition) {
		visitParentName(beanDefinition);
		visitBeanClassName(beanDefinition);
		visitFactoryBeanName(beanDefinition);
		visitFactoryMethodName(beanDefinition);
		visitScope(beanDefinition);
		if (beanDefinition.hasPropertyValues()) {
			visitPropertyValues(beanDefinition.getPropertyValues());
		}
		if (beanDefinition.hasConstructorArgumentValues()) {
			ConstructorArgumentValues cas = beanDefinition.getConstructorArgumentValues();
			visitIndexedArgumentValues(cas.getIndexedArgumentValues());
			visitGenericArgumentValues(cas.getGenericArgumentValues());
		}
	}
	...
}

我们看到,在visitBeanDefinition()方法中,访问了其他数据,比如父类的名字、自己的类名、在IoC容器中的名称等各种信息。
关注微信公众号『 Tom弹架构 』回复“设计模式”可获取完整源码。

【推荐】Tom弹架构:30个设计模式真实案例(附源码),挑战年薪60W不是梦

在这里插入图片描述

本文为“Tom弹架构”原创,转载请注明出处。技术在于分享,我分享我快乐!
如果本文对您有帮助,欢迎关注和点赞;如果您有任何建议也可留言评论或私信,您的支持是我坚持创作的动力。关注微信公众号『 Tom弹架构 』可获取更多技术干货!

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
内容简介: 设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性、程序的重用性。 本课程内容定位学习设计原则,学习设计模式的基础。在实际开发过程中,并不是一定要求所有代码都遵循设计原则,我们要考虑人力、时间、成本、质量,不是刻意追求完美,要在适当的场景遵循设计原则,体现的是一种平衡取舍,帮助我们设计出更加优雅的代码结构。本章将详细介绍开闭原则(OCP)、依赖倒置原则(DIP)、单一职责原则(SRP)、接口隔离原则(ISP)、迪米特法则(LoD)、里氏替换原则(LSP)、合成复用原则(CARP)的具体内容。 为什么需要学习这门课程? 你在日常的开发中,会不会也遇到过同样的问题。系统出现问题,不知道问题究竟出在什么位置;当遇到产品需求,总是对代码缝缝补补,不能很快的去解决。而且平时工作中,总喜欢把代码堆在一起,出现问题时,不知道如何下手,工作效率很低,而且自己的能力也得不到提升。而这些都源于一个问题,那就是软件设计没做好。这门课能帮助你很好的认识设计模式,让你的能力得到提升。课程大纲: 为了让大家快速系统了解设计模式知识全貌,我为您总结了思维导图,帮您梳理学习重点,建议收藏!
Design Patterns: Elements of Reusable Object-Oriented Software(以下简称《设计模式》),一书由Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides合著(Addison-Wesley,1995)。这四位作者常被称为“四人组(Gang of Four)”,而这本书也就被称为“四人组(或 GoF)”书。他们首次给我们总结出一套软件开发可以反复使用的经验,帮助我们提高代码的可重用性、系统的可维护性等,解决软件开发中的复杂问题。设计模式已诞生20多年,其间相继出版的关于设计模式的经典著作不计其数。如果说GoF的《设计模式》是设计模式领域的“圣经”,那么之后出版的各种关于设计模式的书籍可称为“圣经”的“批注版”或者“白话版”。本书正是基于GoF的《设计模式》来编写的。  本课程由《设计模式就该这样学》作者亲授,课程内容和书籍完全同步,可以作为作者对“圣经”实践的精华总结,是一门可以真正能够落地的“设计模式”的课程,也是目前全网唯一一门结合框架源码如何落地“设计模式”这个角度来理解设计模式的课程。本课程将结合JDK、Spring、MyBatis、Tomcat、Netty等经典框架源码展开对设计模式的分析。当然,本课程中还会结合作者多年的“踩坑填坑”经验和“教学答疑”经验,用比“圣经”更深刻、更全面、更通俗、更生动、更有趣、更接地气的方式并且结合真实业务场景分析每种设计模式的优缺点,治愈“设计模式选择困难症”。选设计模式就像相亲选对象,一旦做好了接受TA缺点的准备,那TA就一定属于你。所以,本课程内容对于日常开发而言更具有指导意义。内容均从实战角度出发,在日常应用中,设计模式从来都不是单个设计模式独立使用的。在实际应用中,通常多个设计模式混合使用,你中有我,我中有你。下图完整地描述了设计模式之间的混用关系,希望对大家有所帮助。在《设计模式就该这样学》一书中,还有大量的UML图及易混淆的设计模式对比案例分析,也欢迎大家关注。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Tom弹架构

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值