1700472334
//接受访问者访问
1700472335
1700472336
el.accept（new Visitor（））；
1700472337
1700472338
}
1700472339
1700472340
}
1700472341
1700472342
}
1700472343
1700472344
通过增加访问者，只要是具体元素就非常容易访问，对元素的遍历就更加容易了，甭管它是什么对象，只要它在一个容器中，都可以通过访问者来访问，任务集中化。这就是访问者模式。
1700472345
1700472346
1700472347
1700472348
1700472350
设计模式之禅 25.3 访问者模式的应用
1700472351
1700472352
25.3.1 访问者模式的优点
1700472353
1700472354
❑符合单一职责原则
1700472355
1700472356
具体元素角色也就是Employee抽象类的两个子类负责数据的加载，而Visitor类则负责报表的展现，两个不同的职责非常明确地分离开来，各自演绎变化。
1700472357
1700472358
❑优秀的扩展性
1700472359
1700472360
由于职责分开，继续增加对数据的操作是非常快捷的，例如现在要增加一份给大老板的报表，这份报表格式又有所不同，直接在Visitor中增加一个方法，传递数据后进行整理打印。
1700472361
1700472362
❑灵活性非常高
1700472363
1700472364
例如，数据汇总，就以刚刚我们说的Employee的例子，如果我现在要统计所有员工的工资之和，怎么计算？把所有人的工资for循环加一遍？是个办法，那我再提个问题，员工工资×1.2，部门经理×1.4，总经理×1.8，然后把这些工资加起来，你怎么处理？1.2，1.4，1.8是什么？不是吧？！你没看到领导不论什么时候都比你拿得多，工资奖金就不说了，就是过节发个慰问券也比你多，就是这个系数在作祟。我们继续说你想怎么统计？使用for循环，然后使用instanceof来判断是员工还是经理？这可以解决，但不是个好办法，好办法是通过访问者模式来实现，把数据扔给访问者，由访问者来进行统计计算。
1700472365
1700472366
1700472367
1700472368
1700472369
设计模式之禅 25.3.2 访问者模式的缺点
1700472370
1700472371
❑具体元素对访问者公布细节
1700472372
1700472373
访问者要访问一个类就必然要求这个类公布一些方法和数据，也就是说访问者关注了其他类的内部细节，这是迪米特法则所不建议的。
1700472374
1700472375
❑具体元素变更比较困难
1700472376
1700472377
具体元素角色的增加、删除、修改都是比较困难的，就上面那个例子，你想想，你要是想增加一个成员变量，如年龄age,Visitor就需要修改，如果Visitor是一个还好办，多个呢？业务逻辑再复杂点呢？
1700472378
1700472379
❑违背了依赖倒置转原则
1700472380
1700472381
访问者依赖的是具体元素，而不是抽象元素，这破坏了依赖倒置原则，特别是在面向对象的编程中，抛弃了对接口的依赖，而直接依赖实现类，扩展比较难。
1700472382
1700472383
[
上一页 ]
[ :1.700472334e+09 ]
[
下一页 ]