首页 » 设计模式之禅(第2版) » 设计模式之禅(第2版)全文在线阅读

《设计模式之禅(第2版)》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)角色,这个我们将在混编模式中讲解。