蓝蓝站点

读书笔记

发表于 更新于 分类于 ， ， Waline： 本文字数： 15k 阅读时长 ≈ 13 分钟

12.4 代理模式的扩展

12.4.1 普通代理

在网络上代理服务器设置分为透明代理和普通代理，是什么意思呢？透明代理就是用户不用设置代理服务器地址，就可以直接访问，也就是说代理服务器对用户来说是透明的，不用知道它存在的；普通代理则是需要用户自己设置代理服务器的IP地址，用户必须知道代理的存在。我们设计模式中的普通代理和强制代理也是类似的一种结构，普通代理就是我们要知道代理的存在，也就是类似的GamePlayerProxy这个类的存在，然后才能访问；强制代理则是调用者直接调用真实角色，而不用关心代理是否存在，其代理的产生是由真实角色决定的，这样的解释还是比较复杂，我们还是用实例来讲解。

首先说普通代理，它的要求就是客户端只能访问代理角色，而不能访问真实角色，这是比较简单的。我们以上面的例子作为扩展，我自己作为一个游戏玩家，我肯定自己不练级了，也就是场景类不能再直接new一个GamePlayer对象了，它必须由GamePlayerProxy来进行模拟场景，类图修改如图12-4所示。

image-20210928172440190

图12-4 普通代理类图
改动很小，仅仅修改了两个实现类的构造函数，GamePlayer的构造函数增加了_gamePlayer参数，而代理角色则只要传入代理者名字即可，而不需要说是替哪个对象做代理。GamePlayer类如代码清单12-10所示。

代码清单12-10 普通代理的游戏者

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public class GamePlayer implements IGamePlayer {
    private String name = "";
    //构造函数限制谁能创建对象，并同时传递姓名
    public GamePlayer(IGamePlayer _gamePlayer,String _name) throws Exception{
        if(_gamePlayer == null ){
            throw new Exception("不能创建真实角色！");
        }
        else{
            this.name = _name;
        }
    }
    //打怪，最期望的就是杀老怪
    public void killBoss() {
        System.out.println(this.name + "在打怪！");
    }
    //进游戏之前你肯定要登录吧，这是一个必要条件
    public void login(String user, String password) {
        System.out.println("登录名为"+user + "的用户" + this.name + "登录成功！");
    }
    //升级，升级有很多方法，花钱买是一种，做任务也是一种
    public void upgrade() {
        System.out.println(this.name + " 又升了一级！");
    }
}

在构造函数中，传递进来一个IGamePlayer对象，检查谁能创建真实的角色，当然还可以有其他的限制，比如类名必须为Proxy类等，读者可以根据实际情况进行扩展。 GamePlayerProxy如代码清单12-11所示。

代码清单12-11 普通代理的代理者

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public class GamePlayerProxy implements IGamePlayer {
    private IGamePlayer gamePlayer = null;
    //通过构造函数传递要对谁进行代练
    public GamePlayerProxy(String name){
        try {
            gamePlayer = new GamePlayer(this,name);
        }
        catch (Exception e) {
        // TODO 异常处理 }
    }
    //代练杀怪
    public void killBoss() {
        this.gamePlayer.killBoss();
    }
    //代练登录
    public void login(String user, String password) {
        this.gamePlayer.login(user, password);
    }
    //代练升级
    public void upgrade() {
        this.gamePlayer.upgrade();
    }
}

仅仅修改了构造函数，传递进来一个代理者名称，即可进行代理，在这种改造下，系统更加简洁了，调用者只知道代理存在就可以，不用知道代理了谁。同时场景类也稍作改动， 如代码清单12-12所示。

代码清单12-12 普通代理的场景类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class Client {
    public static void main(String[] args) {
        //然后再定义一个代练者
        IGamePlayer proxy = new GamePlayerProxy("张三");
        //开始打游戏，记下时间戳
        System.out.println("开始时间是：2009-8-25 10:45");
        
        proxy.login("zhangSan", "password");
        //开始杀怪
        proxy.killBoss();
        //升级
        proxy.upgrade();
        //记录结束游戏时间
        System.out.println("结束时间是：2009-8-26 03:40");
    }
}

运行结果完全相同。在该模式下，调用者只知代理而不用知道真实的角色是谁，屏蔽了真实角色的变更对高层模块的影响，真实的主题角色想怎么修改就怎么修改，对高层次的模块没有任何的影响，只要你实现了接口所对应的方法，该模式非常适合对扩展性要求较高的场合。当然，在实际的项目中，一般都是通过约定来禁止new一个真实的角色，这也是一个非常好的方案。

注意 普通代理模式的约束问题，尽量通过团队内的编程规范类约束，因为每一个主题 类是可被重用的和可维护的，使用技术约束的方式对系统维护是一种非常不利的因素。

12.4.2 强制代理

强制代理在设计模式中比较另类，为什么这么说呢？一般的思维都是通过代理找到真实的角色，但是强制代理却是要“强制”，你必须通过真实角色查找到代理角色，否则你不能访问。甭管你是通过代理类还是通过直接new一个主题角色类，都不能访问，只有通过真实角色指定的代理类才可以访问，也就是说由真实角色管理代理角色。这么说吧，高层模块new 了一个真实角色的对象，返回的却是代理角色，这就好比是你和一个明星比较熟，相互认识，有件事情你需要向她确认一下，于是你就直接拨通了明星的电话：

“喂，沙比呀，我要见一下×××导演，你帮下忙了！”

“不行呀衰哥，我这几天很忙呀，你找我的经纪人吧……”

郁闷了吧，你是想直接绕过她的代理，谁知道返回的还是她的代理，这就是强制代理， 你可以不用知道代理存在，但是你的所作所为还是需要代理为你提供。我们把上面的例子稍作修改就可以完成，如图12-5所示。

image-20210928172823578

图12-5 强制代理类图

在接口上增加了一个getProxy方法，真实角色GamePlayer可以指定一个自己的代理，除了代理外谁都不能访问。我们来看代码，先看IGamePlayer接口，如代码清单12-13所示。

代码清单12-13 强制代理的接口类

1
2
3
4
5
6
7
8
9
10
public interface IGamePlayer {
    //登录游戏
    public void login(String user,String password);
    //杀怪，这是网络游戏的主要特色
    public void killBoss();
    //升级
    public void upgrade();
    //每个人都可以找一下自己的代理
    public IGamePlayer getProxy();
}

仅仅增加了一个getProxy方法，指定要访问自己必须通过哪个代理，实现类也要做适当的修改，先看真实角色GamePlayer，如代码清单12-14所示。

代码清单12-14 强制代理的真实角色

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
public class GamePlayer implements IGamePlayer {
    private String name = "";
    //我的代理是谁
    private IGamePlayer proxy = null;
    public GamePlayer(String _name){
        this.name = _name;
    }
    //找到自己的代理
    public IGamePlayer getProxy(){
        this.proxy = new GamePlayerProxy(this);
        return this.proxy;
    }
    //打怪，最期望的就是杀老怪
    public void killBoss() {
        if(this.isProxy()){
            System.out.println(this.name + "在打怪！");
        }
        else{
            System.out.println("请使用指定的代理访问");
        }
    }
    //进游戏之前你肯定要登录吧，这是一个必要条件
    public void login(String user, String password) {
        if(this.isProxy()){
            System.out.println("登录名为"+user+"的用户"+this.name+"登录成功！");
        }
        else{
            System.out.println("请使用指定的代理访问");
            ;
        }
    }
    //升级，升级有很多方法，花钱买是一种，做任务也是一种
    public void upgrade() {
        if(this.isProxy()){
            System.out.println(this.name + " 又升了一级！");
        }
        else{
            System.out.println("请使用指定的代理访问");
        }
    }
    //校验是否是代理访问
    private boolean isProxy(){
        if(this.proxy == null){
            return false;
        }
        else{
            return true;
        }
    }
}

增加了一个私有方法，检查是否是自己指定的代理，是指定的代理则允许访问，否则不允许访问。我们再来看代理角色，如代码清单12-15所示。

代码清单12-15 强制代理的代理类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public class GamePlayerProxy implements IGamePlayer {
    private IGamePlayer gamePlayer = null;
    //构造函数传递用户名
    public GamePlayerProxy(IGamePlayer _gamePlayer){
        this.gamePlayer = _gamePlayer;
    }
    //代练杀怪
    public void killBoss() {
        this.gamePlayer.killBoss();
    }
    //代练登录
    public void login(String user, String password) {
        this.gamePlayer.login(user, password);
    }
    //代练升级
    public void upgrade() {
        this.gamePlayer.upgrade();
    }
    //代理的代理暂时还没有，就是自己
    public IGamePlayer getProxy(){
        return this;
    }
}

代理角色也可以再次被代理，这里我们就没有继续延伸下去了，查找代理的方法就返回自己的实例。代码都写完毕了，我们先按照常规的思路来运行一下，直接new一个真实角色，如代码清单12-16所示。

代码清单12-16 直接访问真实角色

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class Client {
    public static void main(String[] args) {
        //定义一个游戏的角色
        IGamePlayer player = new GamePlayer("张三");
        //开始打游戏，记下时间戳
        System.out.println("开始时间是：2009-8-25 10:45");
        player.login("zhangSan", "password");
        //开始杀怪
        player.killBoss();
        //升级
        player.upgrade();
        //记录结束游戏时间
        System.out.println("结束时间是：2009-8-26 03:40");
    }
}

想想看能运行吗？运行结果如下所示：

1
2
3
4
5
开始时间是：2009-8-25 10:45 
请使用指定的代理访问 
请使用指定的代理访问 
请使用指定的代理访问 
结束时间是：2009-8-26 03:40

它要求你必须通过代理来访问，你想要直接访问它，门儿都没有，好，你要我通过代理来访问，那就生产一个代理，如代码清单12-17所示。

代码清单12-17 直接访问代理类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class Client {
    public static void main(String[] args) {
        //定义一个游戏的角色
        IGamePlayer player = new GamePlayer("张三");
        //然后再定义一个代练者
        IGamePlayer proxy = new GamePlayerProxy(player);
        //开始打游戏，记下时间戳
        System.out.println("开始时间是：2009-8-25 10:45");
        proxy.login("zhangSan", "password");
        //开始杀怪
        proxy.killBoss();
        //升级
        proxy.upgrade();
        //记录结束游戏时间
        System.out.println("结束时间是：2009-8-26 03:40");
    }
}

这次能访问吗？还是不行，结果如下所示：

1
2
3
4
5
开始时间是：2009-8-25 10:45 
请使用指定的代理访问 
请使用指定的代理访问 
请使用指定的代理访问 
结束时间是：2009-8-26 03:40

还是不能访问，为什么呢？它不是真实角色指定的对象，这个代理对象是你自己new出来的，当然真实对象不认了，这就好比是那个明星，人家已经告诉你去找她的代理人了，你随便找个代理人能成吗？你必须去找她指定的代理才成！我们修改一下场景类，如代码清单12-18所示。

代码清单12-18 强制代理的场景类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class Client {
    public static void main(String[] args) {
        //定义一个游戏的角色
        IGamePlayer player = new GamePlayer("张三");
        //获得指定的代理
        IGamePlayer proxy = player.getProxy();
        //开始打游戏，记下时间戳
        System.out.println("开始时间是：2009-8-25 10:45");
        proxy.login("zhangSan", "password");
        //开始杀怪
        proxy.killBoss();
        //升级
        proxy.upgrade();
        //记录结束游戏时间
        System.out.println("结束时间是：2009-8-26 03:40");
    }
}

运行结果如下：

1
2
3
4
5
开始时间是：2009-8-25 10:45 
登录名为zhangSan 的用户张三登录成功！ 
张三在打怪！ 
张三 又升了一级！ 
结束时间是：2009-8-26 03:40

OK，可以正常访问代理了。强制代理的概念就是要从真实角色查找到代理角色，不允许直接访问真实角色。高层模块只要调用getProxy就可以访问真实角色的所有方法，它根本就不需要产生一个代理出来，代理的管理已经由真实角色自己完成。

12.4.3 代理是有个性的

一个类可以实现多个接口，完成不同任务的整合。也就是说代理类不仅仅可以实现主题接口，也可以实现其他接口完成不同的任务，而且代理的目的是在目标对象方法的基础上作增强，这种增强的本质通常就是对目标对象的方法进行拦截和过滤。例如游戏代理是需要收费的，升一级需要5元钱，这个计算功能就是代理类的个性，它应该在代理的接口中定义， 如图12-6所示。

image-20210928173344485

图12-6 代理类的个性
增加了一个IProxy接口，其作用是计算代理的费用。我们先来看IProxy接口，如代码清单12-19所示。

代码清单12-19 代理类的接口

1
2
3
4
public interface IProxy {
    //计算费用
    public void count();
}

仅仅一个方法，非常简单，看GamePlayerProxy带来的变化，如代码清单12-20所示。

代码清单12-20 代理类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public class GamePlayerProxy implements IGamePlayer,IProxy {
    private IGamePlayer gamePlayer = null;
    //通过构造函数传递要对谁进行代练
    public GamePlayerProxy(IGamePlayer _gamePlayer){
        this.gamePlayer = _gamePlayer;
    }
    //代练杀怪
    public void killBoss() {
        this.gamePlayer.killBoss();
    }
    //代练登录
    public void login(String user, String password) {
        this.gamePlayer.login(user, password);
    }
    //代练升级
    public void upgrade() {
        this.gamePlayer.upgrade();
        this.count();
    }
    //计算费用
    public void count(){
        System.out.println("升级总费用是：150元");
    }
}

实现了IProxy接口，同时在upgrade方法中调用该方法，完成费用结算，其他的类都没有任何改动，运行结果如下：

1
2
3
4
5
6
7
开始时间是：2009-8-25 10:45 
登录名为zhangSan 的用户 
张三登录成功！ 
张三在打怪！ 
张三 又升了一级！ 
升级总费用是：150元 
结束时间是：2009-8-26 03:40

好了，代理公司也赚钱了，我的游戏也升级了，皆大欢喜。代理类不仅仅是可以有自己的运算方法，通常的情况下代理的职责并不一定单一，它可以组合其他的真实角色，也可以实现自己的职责，比如计算费用。代理类可以为真实角色预处理消息、过滤消息、消息转发、事后处理消息等功能。当然一个代理类，可以代理多个真实角色，并且真实角色之间可以有耦合关系，读者可以自行扩展一下。

12.4.4 动态代理

放在最后讲的一般都是压轴大戏，动态代理就是如此，上面的章节都是一个引子，动态代理才是重头戏。什么是动态代理？动态代理是在实现阶段不用关心代理谁，而在运行阶段才指定代理哪一个对象。相对来说，自己写代理类的方式就是静态代理。本章节的核心部分就在动态代理上，现在有一个非常流行的名称叫做面向横切面编程，也就是AOP（Aspect Oriented Programming），其核心就是采用了动态代理机制，既然这么重要，我们就来看看动态代理是如何实现的，还是以打游戏为例，类图修改一下以实现动态代理，如图12-7所示。

image-20210928173618506

图12-7 动态代理

在类图中增加了一个InvocationHandler接口和GamePlayIH类，作用就是产生一个对象的代理对象，其中InvocationHandler是JDK提供的动态代理接口，对被代理类的方法进行代理。 我们来看程序，接口保持不变，实现类也没有变化，请参考代码清单12-1和代码清单12-2所示。我们来看DynamicProxy类，如代码清单12-21所示。

代码清单12-21 动态代理类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class GamePlayIH implements InvocationHandler {
    //被代理者
    Class cls =null;
    //被代理的实例
    Object obj = null;
    //我要代理谁
    public GamePlayIH(Object _obj){
        this.obj = _obj;
    }
    //调用被代理的方法
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        Object result = method.invoke(this.obj, args);
        return result;
    }
}

其中invoke方法是接口InvocationHandler定义必须实现的，它完成对真实方法的调用。我们来详细讲解一下InvocationHandler接口，动态代理是根据被代理的接口生成所有的方法， 也就是说给定一个接口，动态代理会宣称“我已经实现该接口下的所有方法了”，那各位读者想想看，动态代理怎么才能实现被代理接口中的方法呢？默认情况下所有的方法返回值都是空的，是的，代理已经实现它了，但是没有任何的逻辑含义，那怎么办？好办，通过InvocationHandler接口，所有方法都由该Handler来进行处理，即所有被代理的方法都由InvocationHandler接管实际的处理任务。

我们接下来看看场景类，如代码清单12-22所示。

代码清单12-22 动态代理的场景类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public class Client {
    public static void main(String[] args) throws Throwable {
        //定义一个痴迷的玩家
        IGamePlayer player = new GamePlayer("张三");
        //定义一个handler
        InvocationHandler handler = new GamePlayIH(player);
        //开始打游戏，记下时间戳
        System.out.println("开始时间是：2009-8-25 10:45");
        //获得类的class
        loader ClassLoader cl = player.getClass().getClassLoader();
        //动态产生一个代理者
        IGamePlayer proxy = (IGamePlayer)Proxy.newProxyInstance(cl,new Class[]{IGamePlayer.class},handler);
        //登录
        proxy.login("zhangSan", "password");
        
        //开始杀怪
        proxy.killBoss();
        //升级
        proxy.upgrade();
        //记录结束游戏时间
        System.out.println("结束时间是：2009-8-26 03:40");
    }
}

很奇怪是吗？不要着急，继续看下去。其运行结果如下：

1
2
3
4
5
6
开始时间是：2009-8-25 10:45 
登录名为zhangSan 的用户 
张三登录成功！ 
张三在打怪！ 
张三 又升了一级！ 
结束时间是：2009-8-26 03:40

我们还是让代练者帮我们打游戏，但是我们既没有创建代理类，也没有实现IGamePlayer 接口，这就是动态代理。别急，动态代理可不仅仅就这么多内容，还有更重要的，如果想让游戏登录后发一个信息给我们，防止账号被人盗用嘛，该怎么处理？直接修改被代理类GamePlayer？这不是一个好办法，好办法如代码清单12-23所示。

代码清单12-23 修正后的动态代理

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class GamePlayIH implements InvocationHandler {
    //被代理者
    Class cls =null;
    //被代理的实例
    Object obj = null;
    //我要代理谁
    public GamePlayIH(Object _obj){
        this.obj = _obj;
    }
    //调用被代理的方法
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        Object result = method.invoke(this.obj, args);
        //如果是登录方法，则发送信息
        if(method.getName().equalsIgnoreCase("login")){
            System.out.println("有人在用我的账号登录！");
        }
        return result;
    }
}

看粗体部分，只要在代理中增加一个判断就可以决定是否要发送信息，运行结果如下：

1
2
3
4
5
6
7
开始时间是：2009-8-25 10:45 
登录名为zhangSan的用户 
张三登录成功！ 
有人在用我的账号登录！ 
张三在打怪！ 
张三 又升了一级！ 
结束时间是：2009-8-26 03:40

太棒了！有人用我的账号就发送一个信息，然后看看自己的账号是不是被人盗了，非常好的方法，这就是AOP编程。AOP编程没有使用什么新的技术，但是它对我们的设计、编码有非常大的影响，对于日志、事务、权限等都可以在系统设计阶段不用考虑，而在设计后通过AOP的方式切过去。既然动态代理是如此诱人，我们来看看通用动态代理模型，类图如图12-8所示。

image-20210928174032665

图12-8 动态代理通用类图

很简单，两条独立发展的线路。动态代理实现代理的职责，业务逻辑Subject实现相关的逻辑功能，两者之间没有必然的相互耦合的关系。通知Advice从另一个切面切入，最终在高层模块也就是Client进行耦合，完成逻辑的封装任务。我们先来看Subject接口，如代码清单12-24所示。

代码清单12-24 抽象主题

1
2
3
4
public interface Subject {
    //业务操作
    public void doSomething(String str);
}

其中的doSomething是一种标识方法，可以有多个逻辑处理方法，实现类如代码清单12- 25所示。

代码清单12-25 真实主题

1
2
3
4
5
6
public class RealSubject implements Subject {
    //业务操作
    public void doSomething(String str) {
        System.out.println("do something!---->" + str);
    }
}

重点是我们的MyInvocationHandler，如代码清单12-26所示。

代码清单12-26 动态代理的Handler类

1
2
3
4
5
6
7
8
9
10
11
12
13
public class MyInvocationHandler implements InvocationHandler {
    //被代理的对象
    private Object target = null;
    //通过构造函数传递一个对象
    public MyInvocationHandler(Object _obj){
        this.target = _obj;
    }
    //代理方法
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        //执行被代理的方法
        return method.invoke(this.target, args);
    }
}

非常简单，所有通过动态代理实现的方法全部通过invoke方法调用。DynamicProxy代码如代码清单12-27所示。

代码清单12-27 动态代理类

1
2
3
4
5
6
7
8
9
10
11
public class DynamicProxy<T> {
    public static <T> T newProxyInstance(ClassLoader loader, Class<?>[] interfaces, InvocationHandler h){
        //寻找JoinPoint连接点，AOP框架使用元数据定义
        if(true){
            //执行一个前置通知
            (new BeforeAdvice()).exec();
        }
        //执行目标，并返回结果
        return (T)Proxy.newProxyInstance(loader,interfaces, h);
    }
}

在这里插入了较多的AOP术语，如在什么地方（连接点）执行什么行为（通知）。我们在这里实现了一个简单的横切面编程，有经验的读者可以看看AOP的配置文件就会明白这段代码的意义了。我们来看通知Advice，也就是我们要切入的类，接口和实现如代码清单12- 28所示。

代码清单12-28 通知接口及实现

1
2
3
4
5
6
7
8
9
public interface IAdvice {
    //通知只有一个方法，执行即可
    public void exec();
}
public class BeforeAdvice implements IAdvice{
    public void exec(){
        System.out.println("我是前置通知，我被执行了！");
    }
}

最后就是看我们怎么调用了，如代码清单12-29所示。

代码清单12-29 动态代理的场景类

1
2
3
4
5
6
7
8
9
10
11
12
public class Client {
    public static void main(String[] args) {
        //定义一个主题
        Subject subject = new RealSubject();
        //定义一个Handler
        InvocationHandler handler = new MyInvocationHandler(subject);
        //定义主题的代理
        Subject proxy = DynamicProxy.newProxyInstance(subject.getClass(). getClassLoader(), subject.getClass().getInterfaces(),handler);
        //代理的行为
        proxy.doSomething("Finish");
    }
}

运行结果如下所示：

1
2
我是前置通知，我被执行了！ 
do something!---->Finish

好，所有的程序都看完了，我们回过头来看看程序是怎么实现的。在DynamicProxy类中，我们有这样的方法：

1
this.obj=Proxy.newProxyInstance(c.getClassLoader(),c.getInterfaces(),new MyInvocationHandler(_obj));

该方法是重新生成了一个对象，为什么要重新生成？你要使用代理呀，注意c.getInterfaces()这句话，这是非常有意思的一句话，是说查找到该类的所有接口，然后实现接口的所有方法。当然了，方法都是空的，由谁具体负责接管呢？是new MyInvocationHandler(_Obj)这个对象。于是我们知道一个类的动态代理类是这样的一个类， 由InvocationHandler的实现类实现所有的方法，由其invoke方法接管所有方法的实现，其动态调用过程如图12-9所示。

image-20210928174531863

图12-9 动态代理调用过程示意图

读者可能注意到我们以上的代码还有更进一步的扩展余地，注意看DynamicProxy类，它是一个通用类，不具有业务意义，如果我们再产生一个实现类是不是就很有意义了呢？如代码清单12-30所示。

代码清单12-30 具体业务的动态代理

1
2
3
4
5
6
7
8
9
10
11
public class SubjectDynamicProxy extends DynamicProxy{
    public static <T> T newProxyInstance(Subject subject){
        //获得ClassLoader
        ClassLoader loader = subject.getClass().getClassLoader();
        //获得接口数组
        Class<?>[] classes = subject.getClass().getInterfaces();
        //获得handler
        InvocationHandler handler = new MyInvocationHandler(subject);
        return newProxyInstance(loader, classes, handler);
    }
}

如此扩展以后，高层模块对代理的访问会更加简单，如代码清单12-31所示。

代码清单12-31 场景类

1
2
3
4
5
6
7
8
9
10
public class Client {
    public static void main(String[] args) {
        //定义一个主题
        Subject subject = new RealSubject();
        //定义主题的代理
        Subject proxy = SubjectDynamicProxy.newProxyInstance(subject);
        //代理的行为
        proxy.doSomething("Finish");
    }
}

是不是更加简单了？可能读者就要提问了，这样与静态代理还有什么区别？都是需要实现一个代理类，有区别，注意看父类，动态代理的主要意图就是解决我们常说的“审计”问题，也就是横切面编程，在不改变我们已有代码结构的情况下增强或控制对象的行为。

注意 要实现动态代理的首要条件是：被代理类必须实现一个接口，回想一下前面的分析吧。当然了，现在也有很多技术如CGLIB可以实现不需要接口也可以实现动态代理的方式。

再次说明，以上的动态代理是一个通用代理框架。如果你想设计自己的AOP框架，完全可以在此基础上扩展，我们设计的是一个通用代理，只要有一个接口，一个实现类，就可以使用该代理，完成代理的所有功效。

发表于 更新于 分类于 ， ， Waline： 本文字数： 418 阅读时长 ≈ 1 分钟

12.3 代理模式的应用

12.3.1 代理模式的优点

  • 职责清晰

真实的角色就是实现实际的业务逻辑，不用关心其他非本职责的事务，通过后期的代理完成一件事务，附带的结果就是编程简洁清晰。

  • 高扩展性

具体主题角色是随时都会发生变化的，只要它实现了接口，甭管它如何变化，都逃不脱如来佛的手掌（接口），那我们的代理类完全就可以在不做任何修改的情况下使用。

  • 智能化

这在我们以上的讲解中还没有体现出来，不过在我们以下的动态代理章节中你就会看到代理的智能化有兴趣的读者也可以看看Struts是如何把表单元素映射到对象上的。

12.3.2 代理模式的使用场景

我相信第一次接触到代理模式的读者肯定很郁闷，为什么要用代理呀？想想现实世界吧，打官司为什么要找个律师？因为你不想参与中间过程的是是非非，只要完成自己的答辩就成，其他的比如事前调查、事后追查都由律师来搞定，这就是为了减轻你的负担。代理模式的使用场景非常多，大家可以看看Spring AOP，这是一个非常典型的动态代理。

发表于 更新于 分类于 ， ， Waline： 本文字数： 1.8k 阅读时长 ≈ 2 分钟

15.5 最佳实践

各位读者可能已经发觉了这样的问题：在我们旅行社的例子中，我们的Receiver角色 （也就是Group的三个实现类）并没有暴露给Client，而在通用的类图和源码中却出现了Client类对Receiver角色的依赖，这是为什么呢？

如果你发现了这个问题，则说明你阅读得非常仔细，好习惯！每一个模式到实际应用的时候都有一些变形，命令模式的Receiver在实际应用中一般都会被封装掉（除非非常必要， 例如撤销处理），那是因为在项目中：约定的优先级最高，每一个命令是对一个或多个Receiver的封装，我们可以在项目中通过有意义的类名或命令名处理命令角色和接收者角色的耦合关系（这就是约定），减少高层模块（Client类）对低层模块（Receiver角色类）的依赖关系，提高系统整体的稳定性。因此，建议大家在实际的项目开发时采用封闭Receiver的方式（当然了，仁者见仁，智者见智），减少Client对Reciver的依赖，该方案只是对Commandd抽象类及其子类有一定的修改，Command类如代码清单15-22所示。

代码清单15-22 完美的Command类

1
2
3
4
5
6
7
8
9
10
public abstract class Command {
    //定义一个子类的全局共享变量
    protected final Receiver receiver;
    //实现类必须定义一个接收者
    public Command(Receiver _receiver){
        this.receiver = _receiver;
    }
    //每个命令类都必须有一个执行命令的方法
    public abstract void execute();
}

在Command父类中声明了一个接收者，通过构造函数约定每个具体命令都必须指定接收者，当然根据开发场景要求也可以有多个接收者，那就需要用集合类型。我们来看具体命令，如代码清单15-23所示。

代码清单15-23 具体的命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
public class ConcreteCommand1 extends Command {
    
    //声明自己的默认接收者
    public ConcreteCommand1(){
        super(new ConcreteReciver1());
    }
    //设置新的接收者
    public ConcreteCommand1(Receiver _receiver){
        super(_receiver);
    }
    //每个具体的命令都必须实现一个命令
    public void execute() {
        //业务处理
        super.receiver.doSomething();
    }
}
public class ConcreteCommand2 extends Command {
    //声明自己的默认接收者
    public ConcreteCommand2(){
        super(new ConcreteReciver2());
    }
    //设置新的接收者
    public ConcreteCommand2(Receiver _receiver){
        super(_receiver);
    }
    //每个具体的命令都必须实现一个命令
    public void execute() {
        //业务处理
        super.receiver.doSomething();
    }
}

这确实简化了很多，每个命令完成单一的职责，而不是根据接收者的不同完成不同的职责。在高层模块的调用时就不用考虑接收者是谁的问题，如代码清单15-24所示。

代码清单15-24 场景类

1
2
3
4
5
6
7
8
9
10
11
public class Client {
    public static void main(String[] args) {
        //首先声明调用者Invoker
        Invoker invoker = new Invoker();
        //定义一个发送给接收者的命令
        Command command = new ConcreteCommand1();
        //把命令交给调用者去执行
        invoker.setCommand(command);
        invoker.action();
    }
}

高层次的模块不需要知道接收者，Perfect!读者可以在实际应用中采用该模式，看看威力如何。

发表于 更新于 分类于 ， ， Waline： 本文字数： 1.8k 阅读时长 ≈ 2 分钟

15.4 命令模式的扩展

15.4.1 未讲完的故事

上面的例子我们还没有说完。想想看，客户要求增加一项需求，那是不是页面也增加， 同时功能也要增加呢？如果不使用命令模式，客户就需要先找需求组，然后找美工组，再找代码组……你想让客户跳楼啊！使用命令模式后，客户只管发命令模式，例如，需要增加一项需求，没问题，我内部调动三个组通力合作，然后把结果反馈给你，这也正是客户需要的。那这个要怎么修改呢？想想看，很简单的！在AddRequirementCommand类的execute方法中增加对PageGroup和CodePage的调用就可以了，修改后的代码如代码清单15-19所示。

代码清单15-19 修改后的增加需求

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class AddRequirementCommand extends Command {
    //执行增加一项需求的命令
    public void execute() {
        //找到需求组
        super.rg.find();
        //增加一份需求
        super.rg.add();
        //页面也要增加
        super.pg.add();
        //功能也要增加
        super.cg.add();
        //给出计划
        super.rg.plan();
    }
}

看看，是不是解决问题了？客户Client只需要发布命令，至于如何执行这个命令，是协调一个对象，还是两个对象，都不需要关心，命令模式做了一层非常好的封装。

15.4.2 反悔问题

我们的例子说到这里是不是应该真的结束了？不，还有一个问题会经常发生的：客户发出命令，要撤回，怎么办？就类似你使用Ctrl+Z组合键（undo功能），发出一个命令，在没有执行（这时只要重新setCommand就可以了）或执行后撤回（执行后撤回是状态变更）该怎么实现呢？

有两种方法可以解决：一是结合备忘录模式还原最后状态，该方法适合接收者为状态的变更情况，而不适合事件处理；二是通过增加一个新的命令，实现事件的回滚。例子中的“删除一个页面”就需要一个反命令：撤销刚刚删除页面的命令，那客户发出这样一个命令，我们该怎么处理呢？

我们这样思考，反命令也是一个命令，那就是Command的一个子类，它实现的功能就是恢复刚刚删除的页面，然后我们再思考，谁能恢复删除的页面呢？当然是页面组了，于是作为接收者的页面组必须还有一个方法恢复最后删除的页面，也就是日志的回滚机制了，指定一个页面，回滚回去。分析完毕，我们来看实现，注意：以下为示意代码，请读者自行在应用中进行实现。修正后的Group如代码清单15-20所示。

代码清单15-20 修改后的Group类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public abstract class Group {
    //甲乙双方分开办公，你要和那个组讨论，你首先要找到这个组
    public abstract void find();
    //被要求增加功能
    public abstract void add();
    //被要求删除功能
    public abstract void delete();
    //被要求修改功能
    public abstract void change();
    //被要求给出所有的变更计划
    public abstract void plan();
    //每个接收者都要对直接执行的任务可以回滚
    public void rollBack(){
        //根据日志进行回滚
    }
}

仅仅增加了一个rollBack的方法，每个接收者都可以对自己实现的任务进行回滚。怎么回滚？根据事务日志进行回滚！新增加的一个命令CancelDeletePageCommand实现撤销刚刚发出的删除命令，如代码清单15-21所示。

代码清单15-21 撤销命令

1
2
3
4
5
6
public class CancelDeletePageCommand extends Command {
    //撤销删除一个页面的命令
    public void execute() {
        super.pg.rollBack();
    }
}

然后就是用Invoker进行调用了，客户选择了执行这个撤销动作，就可以进行撤销操作， 该示意代码确实比较简单，真正实现起来那是异常复杂的，为什么呢？事务日志处理是非常繁琐的处理机制，想想数据库的日志处理吧，你就能想象出这个日志有多复杂！

发表于 更新于 分类于 ， ， Waline： 本文字数： 433 阅读时长 ≈ 1 分钟

15.3 命令模式的应用

15.3.1 命令模式的优点

  • 类间解耦

调用者角色与接收者角色之间没有任何依赖关系，调用者实现功能时只需调用Command 抽象类的execute方法就可以，不需要了解到底是哪个接收者执行。

  • 可扩展性

Command的子类可以非常容易地扩展，而调用者Invoker和高层次的模块Client不产生严重的代码耦合。

  • 命令模式结合其他模式会更优秀

命令模式可以结合责任链模式，实现命令族解析任务；结合模板方法模式，则可以减少 Command子类的膨胀问题。

15.3.2 命令模式的缺点

命令模式也是有缺点的，请看Command的子类：如果有N个命令，问题就出来了，Command的子类就可不是几个，而是N个，这个类膨胀得非常大，这个就需要读者在项目中慎重考虑使用。

15.3.3 命令模式的使用场景

只要你认为是命令的地方就可以采用命令模式，例如，在GUI开发中，一个按钮的点击是一个命令，可以采用命令模式；模拟DOS命令的时候，当然也要采用命令模式；触发－反馈机制的处理等。

发表于 更新于 分类于 ， ， Waline： 本文字数： 2.5k 阅读时长 ≈ 2 分钟

15.2 命令模式的定义

命令模式是一个高内聚的模式，其定义为：

Encapsulate a request as an object,thereby letting you parameterize clients with different requests,queue or log requests,and support undoable operations.（将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。）

命令模式的通用类图如图15-4所示。

image-20210928214814846

图15-4 命令模式的通用类图

在该类图中，我们看到三个角色：

  • Receive接收者角色

该角色就是干活的角色，命令传递到这里是应该被执行的，具体到我们上面的例子中就是Group的三个实现类。

  • Command命令角色

需要执行的所有命令都在这里声明。

  • Invoker调用者角色

接收到命令，并执行命令。在例子中，我（项目经理）就是这个角色。

命令模式比较简单，但是在项目中非常频繁地使用，因为它的封装性非常好，把请求方 （Invoker）和执行方（Receiver）分开了，扩展性也有很好的保障，通用代码比较简单。我们先阅读一下Receiver类，如代码清单15-13所示。

代码清单15-13 通用Receiver类

1
2
3
4
public abstract class Receiver {
    //抽象接收者，定义每个接收者都必须完成的业务
    public abstract void doSomething();
}

很奇怪，为什么Receiver是一个抽象类？那是因为接收者可以有多个，有多个就需要定义一个所有特性的抽象集合——抽象的接收者，其具体的接收者如代码清单15-14所示。

代码清单15-14 具体的Receiver类

1
2
3
4
5
6
7
8
9
10
public class ConcreteReciver1 extends Receiver{
    //每个接收者都必须处理一定的业务逻辑
    public void doSomething(){
    }
}
public class ConcreteReciver2 extends Receiver{
    //每个接收者都必须处理一定的业务逻辑
    public void doSomething(){
    }
}

接收者可以是N个，这要依赖业务的具体定义。命令角色是命令模式的核心，其抽象的命令类如代码清单15-15所示。

代码清单15-15 抽象的Command类

1
2
3
4
public abstract class Command {
    //每个命令类都必须有一个执行命令的方法
    public abstract void execute();
}

根据环境的需求，具体的命令类也可以有N个，其实现类如代码清单15-16所示。

代码清单15-16 具体的Command类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
public class ConcreteCommand1 extends Command {
    //对哪个Receiver类进行命令处理
    private Receiver receiver;
    //构造函数传递接收者
    public ConcreteCommand1(Receiver _receiver){
        this.receiver = _receiver;
    }
    //必须实现一个命令
    public void execute() {
        //业务处理
        this.receiver.doSomething();
    }
}
public class ConcreteCommand2 extends Command {
    //哪个Receiver类进行命令处理
    private Receiver receiver;
    //构造函数传递接收者
    public ConcreteCommand2(Receiver _receiver){
        this.receiver = _receiver;
    }
    //必须实现一个命令
    public void execute() {
        //业务处理
        this.receiver.doSomething();
    }
}

定义了两个具体的命令类，读者可以在实际应用中扩展该命令类。在每个命令类中，通过构造函数定义了该命令是针对哪一个接收者发出的，定义一个命令接收的主体。调用者非常简单，仅实现命令的传递，如代码清单15-17所示。

代码清单15-17 调用者Invoker类

1
2
3
4
5
6
7
8
9
10
11
public class Invoker {
    private Command command;
    //受气包，接受命令
    public void setCommand(Command _command){
        this.command = _command;
    }
    //执行命令
    public void action(){
        this.command.execute();
    }
}

调用者就像是一个受气包，不管什么命令，都要接收、执行！那我们来看高层模块如何调用命令模式，如代码清单15-18所示。

代码清单15-18 场景类

1
2
3
4
5
6
7
8
9
10
11
12
13
public class Client {
    public static void main(String[] args) {
        //首先声明调用者Invoker
        Invoker invoker = new Invoker();
        //定义接收者
        Receiver receiver = new ConcreteReciver1();
        //定义一个发送给接收者的命令
        Command command = new ConcreteCommand1(receiver);
        //把命令交给调用者去执行
        invoker.setCommand(command);
        invoker.action();
    }
}

一个完整的命令模式就此完成，读者可以在此基础上进行扩展。

发表于 更新于 分类于 ， ， Waline： 本文字数： 8.7k 阅读时长 ≈ 8 分钟

25.1 员工的隐私何在

我们在前面讲过了组合模式和迭代器模式。通过组合模式能够把一个公司的人员组织机构树搭建起来，给管理带来非常大的便利，通过迭代器模式把每一个员工都遍历一遍，看看是不是 “有人去世了还在领退休金”，“拿高工资而不干活的尸位素餐”等情况，我们今天要做的就是把这些情况统计成一个报表呈报上去，让领导看看这种恶劣的情况有多严重。

我们公司有700名多技术人员，分布在全国各地，组织架构在组合模式中已经介绍过了，是很常见的家长领导型模式，每个技术人员的岗位都是固定的，你在组织机构的哪棵树下，充当的角色是什么，叶子节点都是非常明确的，每一个员工的信息（如名字、性别、薪水等）都是记录在数据库中，现在有这样一个需求，我要把公司中的所有人员信息都打印汇报上去。我们来看类图，如图25-1所示。

image-20210930101703211

图25-1 员工信息类图

这个类图还是比较简单的，我们定义每个员工都有薪水salary、名称name、性别sex这3 个属性，然后提供了一个抽象方法getOtherInfo由子类进行扩展，同时通过report方法打印出每一个员工的信息，这里使用模板方法模式。我们先来看一下抽象类，如代码清单25-1所示。

代码清单25-1 抽象员工

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
public abstract class Employee {
    public final static int MALE = 0;
    //0代表是男性
    public final static int FEMALE = 1;
    //1代表是女性
    //甭管是谁，都有工资
    private String name;
    //只要是员工那就有薪水
    private int salary;
    
    //性别很重要
    private int sex;
    //以下是简单的getter/setter
    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
    public int getSalary() {
        return salary;
    }
    public void setSalary(int salary) {
        this.salary = salary;
    }
    public int getSex() {
        return sex;
    }
    public void setSex(int sex) {
        this.sex = sex;
    }
    //打印出员工的信息
    public final void report(){
        String info = "姓名：" + this.name + "\t";
        info = info + "性别：" + (this.sex == FEMALE?"女":"男") + "\t";
        info = info + "薪水：" + this.salary + "\t";
        //获得员工的其他信息
        info = info + this.getOtherInfo();
        System.out.println(info);
    }
    //拼装员工的其他信息
    protected abstract String getOtherInfo();
}

先看小兵的实现类，越卑微的人物越能引起共鸣，因为我们有共同的经历、思维和苦难。请看实现类，如代码清单25-2所示。

代码清单25-2 普通员工

1
2
3
4
5
6
7
8
9
10
11
12
13
public class CommonEmployee extends Employee {
    //工作内容，这非常重要，以后的职业规划就是靠它了
    private String job;
    public String getJob() {
        return job;
    }
    public void setJob(String job) {
        this.job = job;
    }
    protected String getOtherInfo(){
        return "工作："+ this.job + "\t";
    }
}

每个实现类都必须实现getOtherInfo信息，通过它获得用户个性信息，我们再来看管理阶层，如代码清单25-3所示。

代码清单25-3 管理阶层

1
2
3
4
5
6
7
8
9
10
11
12
13
public class Manager extends Employee {
    //这类人物的职责非常明确：业绩
    private String performance;
    public String getPerformance() {
        return performance;
    }
    public void setPerformance(String performance) {
        this.performance = performance;
    }
    protected String getOtherInfo(){
        return "业绩："+ this.performance + "\t";
    }
}

Performance这个单词在技术人员的眼里就代表性能，在实际商务英语中可以有Sales Performance（销售业绩）、performance evaluation（业绩评估）等。系统的框架都已经具备 了，那我们来模拟一下这个过程，如代码清单25-4所示。

代码清单25-4 场景类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
public class Client {
    public static void main(String[] args) {
        for(Employee emp:mockEmployee()){
            emp.report();
        }
    }
    //模拟出公司的人员情况，我们可以想象这个数据是通过持久层传递过来的
    public static List<Employee> mockEmployee(){
        List<Employee> empList = new ArrayList<Employee>();
        //产生张三这个员工
        CommonEmployee zhangSan = new CommonEmployee();
        zhangSan.setJob("编写Java程序，绝对的蓝领、苦工加搬运工");
        zhangSan.setName("张三");
        zhangSan.setSalary(1800);
        zhangSan.setSex(Employee.MALE);
        empList.add(zhangSan);
        //产生李四这个员工
        CommonEmployee liSi = new CommonEmployee();
        liSi.setJob("页面美工，审美素质太不流行了！");
        liSi.setName("李四");
        liSi.setSalary(1900);
        liSi.setSex(Employee.FEMALE);
        empList.add(liSi);
        
        //再产生一个经理
        Manager wangWu = new Manager();
        wangWu.setName("王五");
        wangWu.setPerformance("基本上是负值，但是我会拍马屁呀");
        wangWu.setSalary(18750);
        wangWu.setSex(Employee.MALE);
        empList.add(wangWu);
        return empList;
    }
}

先通过mockEmployee来模拟出一个数组，初始化两个员工和一个经理，当然在实际项目中这个数组应该由持久层产生。运行结果如下所示：

1
2
3
姓名：张 三 性别：男 薪水：1800 工作：编写Java程序，绝对的蓝领、苦工加搬运工 
姓名：李 四 性别：女 薪水：1900 工作：页面美工，审美素质太不流行了！ 
姓名：王 五 性别：男 薪水：18750 业绩：基本上是负值，但是我会拍马屁呀

结果出来了，非常正确。我们来想一想实际的情况，人力资源部门拿这份表格会给谁看呢？那当然是大老板了！大老板关心的是什么？关心部门经理的业绩！小兵的情况不是他要了解的，就像战争时期一位将军说：“我一想到我的士兵也有孩子、妻子、父母，我就痛心疾首……但是这是战场，我只能认为他们是一群机器……”是啊，其实我们也一样啊，那问题就出来了：

  • 大老板就看部门经理的报表，小兵的报表可看可不看。
  • 多个大老板的“嗜好”是不同的，主管销售的，则主要关心营销的情况；主管会计的， 则主要关心企业的整体财务运行状态；主管技术的，则主要看技术的研发情况。

综合成一句话，这个报表会修改：数据的修改以及报表的展现修改，按照开闭原则，项目分析的时候已经考虑到这些可能引起变更的因素，就需要在设计时考虑通过扩展来避开未来需求变更而引起的代码修改风险。我们来想一想，每个普通员工类和经理类都用一个方法report（从父类继承过来的），他无法为每一个子类定制特殊的属性，简化类图如图25-2所示。

image-20210930102058552

图25-2 简化类图

我们思考一下，如何提供一个能够为每个子类定制报表的方法呢？可以这样思考，普通员工和管理层员工是两个不同的对象，例如，我邀请一个人过来参观我的家，参观者参观完毕后分别进行描述，那参观的对象不同，描述的结果也当然不同。好，按照这思路，我们把方法report提取到另外一个类Visitor中来实现，如图25-3所示。

image-20210930102136785

图25-3 改造后的简化类图

两个子类的report方法都不需要了，只有Visitor类来实现了report的方法，这个猛一看还真有点委托（intergration）的意味，我们实现出来你就知道这和委托有非常大的差距。详细类图如图25-4所示。

image-20210930102213411

图25-4 改造后的详细类图

在抽象类Employee中增加了accept方法，该方法是一个抽象方法，由子类实现，其意义就是说我这个类可以允许谁来访问，也就是定义一类访问者，在具体的实现类中调用访问者的方法。我们先看访问者接口IVisitor程序，如代码清单25-5所示。

代码清单25-5 访问者接口

1
2
3
4
5
6
public interface IVisitor {
    //首先，定义我可以访问普通员工
    public void visit(CommonEmployee commonEmployee);
    //其次，定义我还可以访问部门经理
    public void visit(Manager manager);
}

该接口的意义是：该接口可以访问两个对象，一个是普通员工，一个是高层员工。我们来看其具体实现类，如代码清单25-6所示。

代码清单25-6 访问者实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
public class Visitor implements IVisitor {
    //访问普通员工，打印出报表
    public void visit(CommonEmployee commonEmployee) {
        System.out.println(this.getCommonEmployee(commonEmployee));
    }
    //访问部门经理，打印出报表
    public void visit(Manager manager) {
        System.out.println(this.getManagerInfo(manager));
    }
    //组装出基本信息
    private String getBasicInfo(Employee employee){
        String info = "姓名：" + employee.getName() + "\t";
        info = info + "性别：" + (employee.getSex() == Employee.FEMALE?"女":"男") + "\t";
        info = info + "薪水：" + employee.getSalary() + "\t";
        return info;
    }
    //组装出部门经理的信息
    private String getManagerInfo(Manager manager){
        String basicInfo = this.getBasicInfo(manager);
        String otherInfo = "业绩："+manager.getPerformance() + "\t";
        return basicInfo + otherInfo;
    }
    //组装出普通员工信息
    private String getCommonEmployee(CommonEmployee commonEmployee){
        String basicInfo = this.getBasicInfo(commonEmployee);
        String otherInfo = "工作："+commonEmployee.getJob()+"\t";
        return basicInfo + otherInfo;
    }
}

在具体的实现类中，定义了两个私有方法，作用就是产生需要打印的数据和格式，然后在访问者访问相关的对象时产生这个报表。抽象员工Employee稍有修改，如代码清单25-7所示。

代码清单25-7 抽象员工类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
public abstract class Employee {
    public final static int MALE = 0;
    //0代表是男性
    public final static int FEMALE = 1;
    //1代表是女性
    //甭管是谁，都有工资
    private String name;
    //只要是员工那就有薪水
    private int salary;
    
    //性别很重要
    private int sex;
    //以下是简单的getter/setter
    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
    public int getSalary() {
        return salary;
    }
    public void setSalary(int salary) {
        this.salary = salary;
    }
    public int getSex() {
        return sex;
    }
    public void setSex(int sex) {
        this.sex = sex;
    }
    //我允许一个访问者访问
    public abstract void accept(IVisitor visitor);
}

抽象员工类有3个变动：

  • 删除了report方法。
  • 增加了accept方法，接受访问者的访问。
  • 删除了getOtherInfo方法。它的实现由访问者来处理，因为访问者对被访问的对象 是“心知肚明”的，非常了解被访问者。

我们继续来看员工实现类，普通员工代码清单25-8所示。

代码清单25-8 普通员工

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class CommonEmployee extends Employee {
    //工作内容，这非常重要，以后的职业规划就是靠它了
    private String job;
    public String getJob() {
        return job;
    }
    public void setJob(String job) {
        this.job = job;
    }
    //我允许访问者访问
    @Override
    public void accept(IVisitor visitor){
        visitor.visit(this);
    }
}

上面是普通员工的实现类，该类的accept方法很简单，这个类就把自身传递过去，也就是让访问者访问本身这个对象。再看Manager类，如代码清单25-9所示。

代码清单25-9 管理层员工

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class Manager extends Employee {
    //这类人物的职责非常明确：业绩
    private String performance;
    public String getPerformance() {
        return performance;
    }
    public void setPerformance(String performance) {
        this.performance = performance;
    }
    //部门经理允许访问者访问
    @Override
    public void accept(IVisitor visitor){
        visitor.visit(this);
    }
}

所有的业务定义都已经完成，我们来看看怎么模拟这个逻辑，如代码清单25-10所示。

代码清单25-10 场景类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
public class Client {
    public static void main(String[] args) {
        for(Employee emp:mockEmployee()){
            emp.accept(new Visitor());
        }
    }
    //模拟出公司的人员情况，我们可以想象这个数据是通过持久层传递过来的
    public static List<Employee> mockEmployee(){
        List<Employee> empList = new ArrayList<Employee>();
        //产生张三这个员工
        CommonEmployee zhangSan = new CommonEmployee();
        zhangSan.setJob("编写Java程序，绝对的蓝领、苦工加搬运工");
        zhangSan.setName("张三");
        zhangSan.setSalary(1800);
        zhangSan.setSex(Employee.MALE);
        empList.add(zhangSan);
        //产生李四这个员工
        CommonEmployee liSi = new CommonEmployee();
        liSi.setJob("页面美工，审美素质太不流行了！");
        liSi.setName("李四");
        
        liSi.setSalary(1900);
        liSi.setSex(Employee.FEMALE);
        empList.add(liSi);
        //再产生一个经理
        Manager wangWu = new Manager();
        wangWu.setName("王五");
        wangWu.setPerformance("基本上是负值，但是我会拍马屁呀");
        wangWu.setSalary(18750);
        wangWu.setSex(Employee.MALE);
        empList.add(wangWu);
        return empList;
    }
}

改动非常少，就黑体那么一行的改动，运行结果如下：

1
2
3
姓名：张 三 性别：男 薪水：1800 工作：编写Java程序，绝对的蓝领、苦工加搬运工 
姓名：李 四 性别：女 薪水：1900 工作：页面美工，审美素质太不流行了！ 
姓名：王 五 性别：男 薪水：18750 业绩：基本上是负值，但是我会拍马屁呀

运行结果也完全相同，那回过头来看看这个程序是怎么实现的：

  • 第一，通过循环遍历所有元素。
  • 第二，每个员工对象都定义了一个访问者。
  • 第三，员工对象把自己作为一个参数调用访问者visit方法。
  • 第四，访问者调用自己内部的计算逻辑，计算出相应的数据和表格元素。
  • 第五，访问者打印出报表和数据。

事情的经过就是这个样子。那我们再来看看上面提到的数据和报表格式都会改变的情况。首先是数据的改变，数据改了当然都要改，说不上两个方案有什么优劣；其次是报表格式的修改，这个方案绝对是有优势的，我只要再产生一个IVisitor的实现类就可以产生一个新的报表格式，而其他的类都不用修改，如果你用Spring开发，那就更好了，在Spring的配置文件中使用的是接口注入，我只要把配置文件中的ref修改一下就行了，其他的都不用修改了！这就是访问者模式的优势所在。