蓝蓝站点

读书笔记

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

29.3 桥梁模式的应用

  • 抽象和实现分离

这也是桥梁模式的主要特点，它完全是为了解决继承的缺点而提出的设计模式。在该模式下，实现可以不受抽象的约束，不用再绑定在一个固定的抽象层次上。

  • 优秀的扩充能力

看看我们的例子，想增加实现？没问题！想增加抽象，也没有问题！只要对外暴露的接口层允许这样的变化，我们已经把变化的可能性减到最小。

  • 实现细节对客户透明

客户不用关心细节的实现，它已经由抽象层通过聚合关系完成了封装。

29.3.2 桥梁模式的使用场景

  • 不希望或不适用使用继承的场景

例如继承层次过渡、无法更细化设计颗粒等场景，需要考虑使用桥梁模式。

  • 接口或抽象类不稳定的场景

明知道接口不稳定还想通过实现或继承来实现业务需求，那是得不偿失的，也是比较失败的做法。

  • 重用性要求较高的场景

设计的颗粒度越细，则被重用的可能性就越大，而采用继承则受父类的限制，不可能出现太细的颗粒度。

29.3.3 桥梁模式的注意事项

桥梁模式是非常简单的，使用该模式时主要考虑如何拆分抽象和实现，并不是一涉及继承就要考虑使用该模式，那还要继承干什么呢？桥梁模式的意图还是对变化的封装，尽量把可能变化的因素封装到最细、最小的逻辑单元中，避免风险扩散。因此读者在进行系统设计时，发现类的继承有N层时，可以考虑使用桥梁模式。

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

28.5 最佳实践

Flyweight是拳击比赛中的特用名词，意思是“特轻量级”，指的是51公斤级比赛，用到设 计模式中是指我们的类要轻量级，粒度要小，这才是它要表达的意思。粒度小了，带来的问 题就是对象太多，那就用共享技术来解决。

享元模式在Java API中也是随处可见，如这样的程序就是一个很好的例子，如代码清单28-17所示。

代码清单28-17 API中的享元模式

1
2
3
4
5
6
7
8
9
10
11
12
public class Test {
    public static void main(String[] args) {
        String str1 = "和谐";
        String str2 = "社会";
        String str3 = "和谐社会";
        String str4;
        str4 = str1 + str2;
        System.out.println(str3 == str4);
        str4 = (str1 + str2).intern();
        System.out.println(str3 == str4);
    }
}

看看Java的帮助文件中String类的intern方法。如果是String的对象池中有该类型的值，则直接返回对象池中的对象，那当然相等了。

需要说明一下的是，虽然可以使用享元模式可以实现对象池，但是这两者还是有比较大的差异，对象池着重在对象的复用上，池中的每个对象是可替换的，从同一个池中获得A对象和B对象对客户端来说是完全相同的，它主要解决复用，而享元模式在主要解决的对象的共享问题，如何建立多个可共享的细粒度对象则是其关注的重点。

发表于 分类于 ， ， Waline： 本文字数： 5.1k 阅读时长 ≈ 5 分钟

28.4 享元模式的扩展

28.4.1 线程安全的问题

线程安全是一个老生常谈的话题，只要使用Java开发都会遇到这个问题，我们之所以要在今天的享元模式中提到该问题，是因为该模式有太大的几率发生线程不安全，为什么呢？

我们还以报考系统为例来说明这个问题。大家有没有想过，为什么要以考试科目+考试地点作为外部状态呢？为什么不能以考试科目或者考试地点作为外部状态呢？这样池中的对象会更少！可以！完全可以！我们把程序以考试科目为外部状态，把享元工厂稍作修改，如代码清单28-10所示。

代码清单28-10 报考信息工厂

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public class SignInfoFactory {
    //池容器
    private static HashMap<String,SignInfo> pool = new HashMap<String,SignInfo>();
    //从池中获得对象
    public static SignInfo getSignInfo(String key){
        //设置返回对象
        SignInfo result = null;
        //池中没有该对象，则建立，并放入池中
        if(!pool.containsKey(key)){
            result = new SignInfo();
            pool.put(key, result);
        }
        else{
            result = pool.get(key);
        }
        return result;
    }
}

下面做很小的改动，只修改了黑色字体部分。为了展示多线程的情况，我们写一个多线程的类，如代码清单28-11所示。

代码清单28-11 多线程场景

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class MultiThread extends Thread {
    private SignInfo signInfo;
    public MultiThread(SignInfo _signInfo){
        
        this.signInfo = _signInfo;
    }
    public void run(){
        if(!signInfo.getId().equals(signInfo.getLocation())){
            System.out.println("编号："+signInfo.getId());
            System.out.println("考试地址："+signInfo.getLocation());
            System.out.println("线程不安全了！");
        }
    }
}

在run方法中判断特殊值，检查是否是线程安全，我们来看看场景类，如代码清单28-12 所示。

代码清单28-12 场景类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class Client {
    public static void main(String[] args) {
        //在对象池中初始化4个对象
        SignInfoFactory.getSignInfo("科目1");
        SignInfoFactory.getSignInfo("科目2");
        SignInfoFactory.getSignInfo("科目3");
        SignInfoFactory.getSignInfo("科目4");
        //取得对象
        SignInfo signInfo = SignInfoFactory.getSignInfo("科目2");
        while(true){
            signInfo.setId("ZhangSan");
            signInfo.setLocation("ZhangSan");
            (new MultiThread(signInfo)).start();
            signInfo.setId("LiSi");
            signInfo.setLocation("LiSi");
            (new MultiThread(signInfo)).start();
        }
    }
}

模拟实际的多线程情况，在对象池中我们保留4个对象，然后启动N多个线程来模拟， 我们马上就看到如下的提示：

1
2
3
编号：LiSi 
考试地址：ZhangSan 
线程不安全了！

看看，线程不安全了吧，这是正常的，设置的享元对象数量太少，导致每个线程都到对象池中获得对象，然后都去修改其属性，于是就出现一些不和谐数据。只要使用Java开发，线程问题是不可避免的，那我们怎么去避免这个问题呢？享元模式是让我们使用共享技术， 而Java的多线程又有如此问题，该如何设计呢？没什么可以参考的标准，只有依靠经验，在需要的地方考虑一下线程安全，在大部分的场景下都不用考虑。我们在使用享元模式时，对象池中的享元对象尽量多，多到足够满足业务为止。

28.4.2 性能平衡

尽量使用Java基本类型作为外部状态。在报考系统中，我们不考虑系统的修改风险，完全可以重新建立一个类作为外部状态，因为这才完全符合面向对象编程的理念。好，我们实现处理，先看类图，如图28-4所示。

image-20210930115503856

图28-4 类作为外部状态

我们首先来看ExtrinsicState外部状态类，如代码清单28-13所示。

代码清单28-13 外部状态类

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 ExtrinsicState {
    //考试科目
    private String subject;
    //考试地点
    private String location;
    public String getSubject() {
        return subject;
    }
    public void setSubject(String subject) {
        
        this.subject = subject;
    }
    public String getLocation() {
        return location;
    }
    public void setLocation(String location) {
        this.location = location;
    }
    @Override
    public boolean equals(Object obj){
        if(obj instanceof ExtrinsicState){
            ExtrinsicState state = (ExtrinsicState)obj;
            return state.getLocation().equals(location) && state.getSubject().equals(subject);
        }
        return false;
    }
    @Override
    public int hashCode(){
        return subject.hashCode() + location.hashCode();
    }
}

注意，一定要覆写equals和hashCode方法，否则它作为HashMap中的key值是根本没有意义的，只有hashCode值相等，并且equals返回结果为true，两个对象才相等，也只有在这种情况下才有可能从对象池中查找获得对象。

1
注意 如果把一个对象作为Map类的键值，一定要确保重写了equals和hashCode方法， 否则会出现通过键值搜索失败的情况，例如map.get(object)、map.contains(object)等会返回失败的结果。

SignInfo的修改较小，仅在SignInfo中引入该ExtrinsicState外部状态对象，在此不再赘述。 我们再来看享元工厂，它是以ExtrinsicState类作为外部状态，如代码清单28-14所示。

代码清单28-14 享元工厂

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public class SignInfoFactory {
    //池容器
    private static HashMap<ExtrinsicState,SignInfo> pool = new HashMap <ExtrinsicState,SignInfo>();
    //从池中获得对象
    public static SignInfo getSignInfo(ExtrinsicState key){
        //设置返回对象
        SignInfo result = null;
        //池中没有该对象，则建立，并放入池中
        if(!pool.containsKey(key)){
            result = new SignInfo();
            pool.put(key, result);
        }
        else{
            result = pool.get(key);
        }
        return result;
    }
}

重点是看看我们的场景类，我们来测试一下性能差异，如代码清单28-15所示。

代码清单28-15 场景类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class Client {
    public static void main(String[] args) {
        //初始化对象池
        ExtrinsicState state1 = new ExtrinsicState();
        state1.setSubject("科目1");
        state1.setLocation("上海");
        SignInfoFactory.getSignInfo(state1);
        ExtrinsicState state2 = new ExtrinsicState();
        state2.setSubject("科目1");
        state2.setLocation("上海");
        //计算执行100万次需要的时间
        long currentTime = System.currentTimeMillis();
        for(int i=0;i<1000000;i++){
            SignInfoFactory.getSignInfo(state2);
        }
        long tailTime = System.currentTimeMillis();
        System.out.println("执行时间："+(tailTime - currentTime) + " ms");
    }
}

运行结果如下所示：

1
执行时间：172 ms

同样，我们看看以String类型作为外部状态的运行情况，如代码清单28-16所示。

代码清单28-16 场景类

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) {
        String key1 = "科目1上海";
        String key2 = "科目1上海";
        //初始化对象池
        SignInfoFactory.getSignInfo(key1);
        //计算执行10万次需要的时间
        long currentTime = System.currentTimeMillis();
        
        for(int i=0;i<10000000;i++){
            SignInfoFactory.getSignInfo(key2);
        }
        long tailTime = System.currentTimeMillis();
        System.out.println("执行时间："+(tailTime - currentTime) + " ms");
    }
}

运行结果如下所示：

1
执行时间：78 ms

看到没？一半的效率，这还是非常简单的享元对象，看看我们重写的equals方法和hashCode方法，这段代码是必须实现的，如果比较复杂，这个时间差异会更大。

各位，想想看，使用自己编写的类作为外部状态，必须覆写equals方法和hashCode方法，而且执行效率还比较低，这种吃力不讨好的事情最好别做，外部状态最好以Java的基本类型作为标志，如String、int等，可以大幅地提升效率。

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

28.3 享元模式的应用

28.3.1 享元模式的优点和缺点

享元模式是一个非常简单的模式，它可以大大减少应用程序创建的对象，降低程序内存的占用，增强程序的性能，但它同时也提高了系统复杂性，需要分离出外部状态和内部状态，而且外部状态具有固化特性，不应该随内部状态改变而改变，否则导致系统的逻辑混乱。

28.3.2 享元模式的使用场景

在如下场景中则可以选择使用享元模式。

  • 系统中存在大量的相似对象。
  • 细粒度的对象都具备较接近的外部状态，而且内部状态与环境无关，也就是说对象没 有特定身份。
  • 需要缓冲池的场景。

发表于 分类于 ， ， Waline： 本文字数： 1.1k 阅读时长 ≈ 1 分钟

26.4 最佳实践

上面的例子可能比较复杂，请各位看官耐心看，看完肯定有所收获。我翻遍了所有能找得到的资料（关于这个电梯的例子也是由《Design Pattern for Dummies》这本书激发出来的），基本上没有一本把这个状态模式讲透彻的（当然，还是有几本讲得不错），我不敢说我就讲得透彻，大家都只讲了一个状态到另一个状态的过渡。状态间的过渡是固定的，举个简单的例子，如图26-6所示。

image-20210930111216250

图26-6 简单状态切换示意图

这个状态图是很多书上都有的，状态A只能切换到状态B，状态B再切换到状态C。举例最多的就是TCP监听的例子。TCP有3个状态：等待状态、连接状态、断开状态，然后这3个状态按照顺序循环切换。按照这个状态变更来讲解状态模式，我认为是不太合适的，为什么呢？你在项目中很少看到一个状态只能过渡到另一个状态情形，项目中遇到的大多数情况都是一个状态可以转换为几种状态，如图26-7所示。

image-20210930111248277

图26-7 复杂状态切换示意图
状态B既可以切换到状态C，又可以切换到状态D，而状态D也可以切换到状态A或状态B，这在项目分析过程中有一个状态图可以完整地展示这种蜘蛛网结构，例如，一些收费网站的用户就有很多状态，如普通用户、普通会员、VIP会员、白金级用户等，这个状态的变更你不允许跳跃？！这不可能，所以我在例子中就举了一个比较复杂的应用，基本上可以实现状态间自由切换，这才是最经常用到的状态模式。

再提一个问题，状态间的自由切换，那会有很多种呀，你要挨个去牢记一遍吗？比如上面那个电梯的例子，我要一个正常的电梯运行逻辑，规则是开门->关门->运行->停止；还要一个紧急状态（如火灾）下的运行逻辑，关门->停止，紧急状态时，电梯当然不能用了；再要一个维修状态下的运行逻辑，这个状态任何情况都可以，开着门电梯运行？可以！门来回开关？可以！永久停止不动？可以！那这怎么实现呢？需要我们把已经有的几种状态按照一定的顺序再重新组装一下，那这个是什么模式？什么模式？大声点！建造者模式！对，建造模式+状态模式会起到非常好的封装作用。

更进一步，应该有部分读者做过工作流开发，如果不是土制框架，那么就应该有个状态机管理（即使是土制框架也应该有），如一个Activity（节点）有初始化状态（Initialized State）、挂起状态（Suspended State）、完成状态（Completed State）等，流程实例也有这么多状态，那这些状态怎么管理呢？通过状态机（State Machine）来管理，那状态机是个什么东西呢？就是我们上面提到的Context类的升级变态BOSS！

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

26.3 状态模式的应用

26.3.1 状态模式的优点

  • 结构清晰

避免了过多的switch…case或者if…else语句的使用，避免了程序的复杂性,提高系统的可维护性。

  • 遵循设计原则

很好地体现了开闭原则和单一职责原则，每个状态都是一个子类，你要增加状态就要增加子类，你要修改状态，你只修改一个子类就可以了。

  • 封装性非常好

这也是状态模式的基本要求，状态变换放置到类的内部来实现，外部的调用不用知道类内部如何实现状态和行为的变换。

26.3.2 状态模式的缺点

状态模式既然有优点，那当然有缺点了。但只有一个缺点，子类会太多，也就是类膨胀。如果一个事物有很多个状态也不稀奇，如果完全使用状态模式就会有太多的子类，不好管理，这个需要大家在项目中自己衡量。其实有很多方式可以解决这个状态问题，如在数据库中建立一个状态表，然后根据状态执行相应的操作，这个也不复杂，看大家的习惯和嗜好了。

26.3.3 状态模式的使用场景

  • 行为随状态改变而改变的场景

这也是状态模式的根本出发点，例如权限设计，人员的状态不同即使执行相同的行为结果也会不同，在这种情况下需要考虑使用状态模式。

  • 条件、分支判断语句的替代者

在程序中大量使用switch语句或者if判断语句会导致程序结构不清晰，逻辑混乱，使用状态模式可以很好地避免这一问题，它通过扩展子类实现了条件的判断处理。

26.3.4 状态模式的注意事项

状态模式适用于当某个对象在它的状态发生改变时，它的行为也随着发生比较大的变化，也就是说在行为受状态约束的情况下可以使用状态模式，而且使用时对象的状态最好不要超过5个。

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

25.5 最佳实践

访问者模式是一种集中规整模式，特别适用于大规模重构的项目，在这一个阶段需求已经非常清晰，原系统的功能点也已经明确，通过访问者模式可以很容易把一些功能进行梳理，达到最终目的——功能集中化，如一个统一的报表运算、UI展现等，我们还可以与其他模式混编建立一套自己的过滤器或者拦截器，请大家参考混编模式的相关章节。

发表于 分类于 ， ， Waline： 本文字数： 7.2k 阅读时长 ≈ 7 分钟

25.4 访问者模式的扩展

访问者模式是经常用到的模式，虽然你不注意，有可能你起的名字也不是什么Visitor， 但是它确实是非常容易使用到的，在这里我提出两个扩展的功能供大家参考。

25.4.1 统计功能

在例子中我们也提到访问者的统计功能，汇总和报表是金融类企业非常常用的功能，基本上都是一堆的计算公式，然后出一个报表，很多项目采用了数据库的存储过程来实现，我不是很推荐这种方式，除非海量数据处理，一个晚上要批处理上亿、几十亿条的数据，除了存储过程来处理还没有其他办法，你要是用应用服务器来处理，连接数据库的网络就是处于100%占用状态，一个晚上也未必能处理完这批数据！除了这种海量数据外，我建议数据统计和报表的批处理通过访问者模式来处理会比较简单。好，那我们来统计一下公司人员的工资总额，先看类图，如图25-6所示。

image-20210930103615070

图25-6 统计功能的访问者模式
没什么变化？仔细看IVisitor接口，增加了一个getTotalSalary方法，在Visitor实现类中实现该方法。我们先看接口，如代码清单25-17所示。

代码清单25-17 抽象访问者

1
2
3
4
5
6
7
8
public interface IVisitor {
    //首先定义我可以访问普通员工
    public void visit(CommonEmployee commonEmployee);
    //其次定义，我还可以访问部门经理
    public void visit(Manager manager);
    //统计所有员工工资总和
    public int getTotalSalary();
}

这就多了一个getTotalSalary方法。我们再来看实现类，如代码清单25-18所示。

代码清单25-18 具体访问者

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public class Visitor implements IVisitor {
    //部门经理的工资系数是5
    private final static int MANAGER_COEFFICIENT = 5;
    //员工的工资系数是2
    private final static int COMMONEMPLOYEE_COEFFICIENT = 2;
    //普通员工的工资总和
    private int commonTotalSalary = 0;
    //部门经理的工资总和
    private int managerTotalSalary =0;
    //计算部门经理的工资总和
    private void calManagerSalary(int salary){
        this.managerTotalSalary = this.managerTotalSalary + salary *MANAGER_COEFFICIENT ;
    }
    //计算普通员工的工资总和
    private void calCommonSlary(int salary){
        this.commonTotalSalary = this.commonTotalSalary + salary*COMMONEMPLOYEE_COEFFICIENT;
    }
    //获得所有员工的工资总和
    public int getTotalSalary(){
        return this.commonTotalSalary + this.managerTotalSalary;
    }
}

员工和经理层的信息就不再展示了，请参考代码清单25-6。程序还是比较简单的，分别计算普通员工和经理级员工的工资总和，然后加起来。注意，我们在实现时已经考虑员工工资和经理工资的系数不同。

我们再来看Client类的模拟，如代码清单25-19所示。

代码清单25-19 场景类

1
2
3
4
5
6
7
8
9
10
public class Client {
    public static void main(String[] args) {
        IVisitor visitor = new Visitor();
        for(Employee emp:mockEmployee()){
            emp.accept(visitor);
        }
        System.out.println("本公司的月工资总额是："+visitor.getTotalSalary());
    }
    
}

其中mockEmployee静态方法没有任何改动，请参考代码清单25-10，在此不再赘述。运行结果如下所示：

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

然后你想修改工资的系数，没有问题！想换个展示格式，也没有问题！多多练习吧，这都是非常简单的。

25.4.2 多个访问者

在实际的项目中，一个对象，多个访问者的情况非常多。其实我们上面例子就应该是两个访问者，为什么呢？报表分两种：第一种是展示表，通过数据库查询，把结果展示出来， 这个就类似于我们的那个列表；第二种是汇总表，这个是需要通过模型或者公式计算出来的，一般都是批处理结果，这个类似于我们计算工资总额，这两种报表格式是对同一堆数据的两种处理方式。从程序上看，一个类就有个不同的访问者了。修改一下类图，如图25-7所示。

类图看着挺复杂，其实也没什么复杂的，只是多了两个接口和两个实现类，分别负责展示表和汇总表的业务处理，IVisitor接口没有改变，请参考代码清单25-5所示代码，这里不再赘述。我们来看展示报表接口，如代码清单25-20所示。

代码清单25-20 展示表接口

1
2
3
4
public interface IShowVisitor extends IVisitor {
    //展示报表
    public void report();
}

展示表的实现也比较简单，如代码清单25-21所示。

代码清单25-21 具体展示表

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

image-20210930104007400

图25-7 多访问者的类图

汇总表实现数据汇总功能，其接口如代码清单25-22所示。

代码清单25-22 汇总表接口

1
2
3
4
public interface ITotalVisitor extends IVisitor {
    //统计所有员工工资总和
    public void totalSalary();
}

就一句话，非常简单，我们再来看具体的汇总表访问者，如代码清单25-23所示。

代码清单25-23 具体汇总表

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public class TotalVisitor implements ITotalVisitor {
    //部门经理的工资系数是5
    private final static int MANAGER_COEFFICIENT = 5;
    //员工的工资系数是2
    private final static int COMMONEMPLOYEE_COEFFICIENT = 2;
    //普通员工的工资总和
    private int commonTotalSalary = 0;
    //部门经理的工资总和
    private int managerTotalSalary =0;
    public void totalSalary() {
        System.out.println("本公司的月工资总额是" + (this.commonTotalSalary + this.managerTotalSalary));
    }
    //访问普通员工，计算工资总额
    public void visit(CommonEmployee commonEmployee) {
        this.commonTotalSalary = this.commonTotalSalary + commonEmployee.getSalary() *COMMONEMPLOYEE_COEFFICIENT;
    }
    //访问部门经理，计算工资总额
    public void visit(Manager manager) {
        this.managerTotalSalary = this.managerTotalSalary + manager.getSalary() *MANAGER_COEFFICIENT ;
    }
}

最后看我们的场景类如何计算出工资总额，如代码清单25-24所示。

代码清单25-24 场景类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public class Client {
    public static void main(String[] args) {
        //展示报表访问者
        IShowVisitor showVisitor = new ShowVisitor();
        //汇总报表的访问者
        ITotalVisitor totalVisitor = new TotalVisitor();
        for(Employee emp:mockEmployee()){
            emp.accept(showVisitor);
            //接受展示报表访问者
            emp.accept(totalVisitor);
            //接受汇总表访问者
        }
        //展示报表
        showVisitor.report();
        //汇总报表
        totalVisitor.totalSalary();
    }
}

运行结果如下所示：

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

大家可以再深入地想象，一堆数据从几个角度来分析，那是什么？即数据挖掘（Data Mining），数据的上切、下钻等处理，大家有兴趣看可以翻看数据挖掘或者商业智能（BI） 的书。

25.4.3 双分派

说到访问者模式就不得不提一下双分派（double dispatch）问题，什么是双分派呢？我们先来解释一下什么是单分派（single dispatch）和多分派（multiple dispatch），单分派语言处理一个操作是根据请求者的名称和接收到的参数决定的，在Java中有静态绑定和动态绑定之说，它的实现是依据重载（overload）和覆写（override）实现的，我们来说一个简单的例子。

例如，演员演电影角色，一个演员可以扮演多个角色，我们先定义一个影视中的两个角色：功夫主角和白痴配角，如代码清单25-25所示。

代码清单25-25 角色接口及实现类

1
2
3
4
5
6
7
8
9
public interface Role {
    //演员要扮演的角色
}
public class KungFuRole implements Role {
    //武功天下第一的角色
}
public class IdiotRole implements Role {
    //一个弱智角色
}

角色有了，我们再定义一个演员抽象类，如代码清单25-26所示。

代码清单25-26 抽象演员

1
2
3
4
5
6
7
8
9
10
public abstract class AbsActor {
    //演员都能够演一个角色
    public void act(Role role){
        System.out.println("演员可以扮演任何角色");
    }
    //可以演功夫戏
    public void act(KungFuRole role){
        System.out.println("演员都可以演功夫角色");
    }
}

很简单，这里使用了Java的重载，我们再来看青年演员和老年演员，采用覆写的方式来细化抽象类的功能，如代码清单25-27所示。

代码清单25-27 青年演员和老年演员

1
2
3
4
5
6
7
8
9
10
11
12
public class YoungActor extends AbsActor {
    //年轻演员最喜欢演功夫戏
    public void act(KungFuRole role){
        System.out.println("最喜欢演功夫角色");
    }
}
public class OldActor extends AbsActor {
    //不演功夫角色
    public void act(KungFuRole role){
        System.out.println("年龄大了，不能演功夫角色");
    }
}

覆写和重载都已经实现，我们编写一个场景，如代码清单25-28所示。

代码清单25-28 场景类

1
2
3
4
5
6
7
8
9
10
11
public class Client {
    public static void main(String[] args) {
        //定义一个演员
        AbsActor actor = new OldActor();
        //定义一个角色
        Role role = new KungFuRole();
        //开始演戏
        actor.act(role);
        actor.act(new KungFuRole());
    }
}

猜猜看运行结果是什么？很简单，运行结果如下所示。

1
2
演员可以扮演任何角色
年龄大了，不能演功夫角色

重载在编译器期就决定了要调用哪个方法，它是根据role的表面类型而决定调用act(Role role)方法，这是静态绑定；而Actor的执行方法act则是由其实际类型决定的，这是动态绑定。

一个演员可以扮演很多角色，我们的系统要适应这种变化，也就是根据演员、角色两个对象类型，完成不同的操作任务，该如何实现呢？很简单，我们让访问者模式上场就可以解决该问题，只要把角色类稍稍修改即可，如代码清单25-29所示。

代码清单25-29 引入访问者模式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public interface Role {
    //演员要扮演的角色
    public void accept(AbsActor actor);
}
public class KungFuRole implements Role {
    //武功天下第一的角色
    public void accept(AbsActor actor){
        actor.act(this);
    }
}
public class IdiotRole implements Role {
    //一个弱智角色，由谁来扮演
    public void accept(AbsActor actor){
        actor.act(this);
    }
}

场景类稍有改动，如代码清单25-30所示。

代码清单25-30 场景类

1
2
3
4
5
6
7
8
9
10
public class Client {
    public static void main(String[] args) {
        //定义一个演员
        AbsActor actor = new OldActor();
        //定义一个角色
        Role role = new KungFuRole();
        //开始演戏
        role.accept(actor);
    }
}

运行结果如下所示。

1
年龄大了，不能演功夫角色

看到没？不管演员类和角色类怎么变化，我们都能够找到期望的方法运行，这就是双反派。双分派意味着得到执行的操作决定于请求的种类和两个接收者的类型，它是多分派的一个特例。从这里也可以看到Java是一个支持双分派的单分派语言。

发表于 分类于 ， ， Waline： 本文字数： 1.1k 阅读时长 ≈ 1 分钟

25.3 访问者模式的应用

25.3.1 访问者模式的优点

  • 符合单一职责原则

具体元素角色也就是Employee抽象类的两个子类负责数据的加载，而Visitor类则负责报表的展现，两个不同的职责非常明确地分离开来，各自演绎变化。

  • 优秀的扩展性

由于职责分开，继续增加对数据的操作是非常快捷的，例如，现在要增加一份给大老板的报表，这份报表格式又有所不同，直接在Visitor中增加一个方法，传递数据后进行整理打印。

  • 灵活性非常高

例如，数据汇总，就以刚刚我们说的Employee的例子，如果我现在要统计所有员工的工资之和，怎么计算？把所有人的工资for循环加一遍？是个办法，那我再提个问题，员工工资 ×1.2，部门经理×1.4，总经理×1.8，然后把这些工资加起来，你怎么处理？1.2，1.4，1.8是什么？不是吧？！你没看到领导不论什么时候都比你拿得多，工资奖金就不说了，就是过节发个慰问券也比你多，就是这个系数在作祟。我们继续说你想怎么统计？使用for循环，然后使用instanceof来判断是员工还是经理？这可以解决，但不是个好办法，好办法是通过访问者模式来实现，把数据扔给访问者，由访问者来进行统计计算。

25.3.2 访问者模式的缺点

  • 具体元素对访问者公布细节

访问者要访问一个类就必然要求这个类公布一些方法和数据，也就是说访问者关注了其他类的内部细节，这是迪米特法则所不建议的。

  • 具体元素变更比较困难

具体元素角色的增加、删除、修改都是比较困难的，就上面那个例子，你想想，你要是想增加一个成员变量，如年龄age，Visitor就需要修改，如果Visitor是一个还好办，多个呢？ 业务逻辑再复杂点呢？

  • 违背了依赖倒置转原则

访问者依赖的是具体元素，而不是抽象元素，这破坏了依赖倒置原则，特别是在面向对象的编程中，抛弃了对接口的依赖，而直接依赖实现类，扩展比较难。

25.3.3 访问者模式的使用场景

  • 一个对象结构包含很多类对象，它们有不同的接口，而你想对这些对象实施一些依赖 于其具体类的操作，也就说是用迭代器模式已经不能胜任的情景。
  • 需要对一个对象结构中的对象进行很多不同并且不相关的操作，而你想避免让这些操 作“污染”这些对象的类。

总结一下，在这种地方你一定要考虑使用访问者模式：业务规则要求遍历多个不同的对象。这本身也是访问者模式出发点，迭代器模式只能访问同类或同接口的数据（当然了，如果你使用instanceof，那么能访问所有的数据，这没有争论），而访问者模式是对迭代器模式的扩充，可以遍历不同的对象，然后执行不同的操作，也就是针对访问的对象不同，执行不同的操作。访问者模式还有一个用途，就是充当拦截器（Interceptor）角色，这个我们将在混编模式中讲解。

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

24.5 最佳实践

备忘录模式是我们设计上“月光宝盒”，可以让我们回到需要的年代；是程序数据的“后悔药”，吃了它就可以返回上一个状态；是设计人员的定心丸，确保即使在最坏的情况下也能获得最近的对象状态。如果大家看懂了的话，请各位在设计的时候就不要使用数据库的临时表作为缓存备份数据了，虽然是一个简单的办法，但是它加大了数据库操作的频繁度，把压力下放到数据库了，最好的解决办法就是使用备忘录模式。