访问者模式

1.基本概念 使用一个访问者类，改变元素类的执行算法，通过这种方式，元素的执行算法可以随着访问者改变而改变 目的：将数据结构与数据操作分离 应用实例： 您在朋友家做客，您是访问者，朋友接受您的访问，您通过朋友的描述，然后对朋友的描述做出一个判断，这就是访问者模式。 UML 　　 2.代码实现 1 package com.chengjie; 2 3 interface ComputerPart1 { 4 public void accept(ComputerPartVisitor computerPartVisitor); 5 } 6 7 class KeyBoard implements ComputerPart1 { 8 @Override 9 public void accept(ComputerPartVisitor computerPartVisitor) { 10 computerPartVisitor.visit(this); 11 } 12 } 13 14 class Monitor implements ComputerPart1 { 15 16 @Override 17 public void accept(ComputerPartVisitor computerPartVisitor) { 18 computerPartVisitor.visit(this);

场景：部队招人时的面试官以及工厂招人的面试官是visitor，被面试的男人和女人是被访问的Element， 要点： 1. 抽象的Person（又叫Element）里有个accept(visitor)函数，该函数里调用了visitor.visit(this)。 2. 抽象的Visitor（抽象面试官）里分别定义了visit(Man)和visit(Women)两个抽象方法。 方法名相同，但参数不同，应该叫做重载吧。 3. 具体的ConcreteVisitor（例如ArmyVisitor和FactoryVisitor）根据自己的逻辑对visit(Man)和visit(Women)进行了实现。这个没啥。 下面这个UML图我觉得不标准，Visitor应该有虚线的依赖具体的Main和Woman，而抽象的Person应该有虚线的依赖接口Visitor 有几个疑问，为什么不能在使用程序里（比如Main()函数）直接调用visitor.visit(man)，而非要通过man.accept(visitor)来绕一圈呢？有啥好处？ ---------分割线以下的是我后来想明白了补充的----------------------------------------------------------------------- 如果你用的语言支持函数重载，那么就像我的疑问里提的

这是设计模式的最后一篇，最近事还是挺多，自己的东西还是没进步。其实我这个人不用和领导套近乎，我有自己的职业素养，工匠精神。我喜欢独处，喜欢自由，也喜欢女人，我订婚后也很幸福。 今年我31周岁了，现在不是回想以前的时候，但是还是我应该努力的时候，不停的上进，坚持最后一定会成功！最怕傻逼式的坚持！ 朋友之间相处不要牵扯借钱的事，大钱不借，要么给。 意思要守住原则，这样才能长久。 面向过程语言开发时，有句话是算法+数据=程序。 面向对象开发同样适用。算法等于对象引用的方法，数据等于对象中的属性字段。 我其他设计模式中一直提，两个对象要能通信必须能找到对方的（内存）空间。 访问者模式同样是这个道理：什么也不说，直接上例子，我来解释！ //抽象的思路， abstract class Action { //依赖Man对象，即只在这个方法中才能访问到Man对象 public abstract void GetManConclusion(Man concreteElementA); public abstract void GetWomanConclusion(Woman concreteElementB); } //具体的内存对象 class Success : Action { public override void GetManConclusion(Man concreteElementA

“男人成功时，背后多半有一个伟大的女人。 女人成功时，背后大多有一个不成功的男人。 男人失败时，闷头喝酒，谁也不用劝。 女人失败时，眼泪汪汪，谁也劝不了。 男人恋爱时，凡事不懂也要装懂。 女人恋爱时，遇事懂也装作不懂。” 根据上面这段话，可变成以下代码： /// <summary> /// 人员 /// </summary> public abstract class Person { //得到结论或反应 public abstract void GetConclusion(Action action); } /// <summary> /// 男人 /// </summary> public class Man : Person { public override void GetConclusion(Action action) { action.ManConclusion(this); } } /// <summary> /// 女人 /// </summary> public class Woman : Person { public override void GetConclusion(Action action) { action.WomanConclusion(this); } } /// <summary> /// 表现 /// </summary> public

一、概述 一般问题： 对象结构比较稳定，但经常需要在此对象结构上定义新的操作。 核心方案： 封装一些作用于某种数据结构中的各元素的操作，它可以在不改变这个数据结构的前提下定义作用于这些元素的新的操作。 设计意图： 一般情况下，一个类会封装一些属性，同时会提供访问这些属性的方法。如果这个类的属性是稳定的，但是访问属性的接口却经常变动，也就是经常需要修改类代码，显然不符合“开闭原则”。在设计模式里，没有什么是不能拆的，既然数据结构稳定，数据操作经常改变，那就把数据操作封装到单独的类中好了，然后再在这些类中定义好对每种数据类型的访问方法，这就是最初的访问者模式了。 访问者模式的类图在众多设计模式里属于比较复杂的。我们分成两部分来看： （1）数据结构端 Element定义元素类，是所有数据类型的抽象类，需要定义accept接口，用来接受访问者。 ObjectStructure为元素类容器 （2）数据访问端 Visitor定义访问者类，是所有访问者的抽象类，需要定义各个元素的visite接口，用于对不同元素的区别对待 二、应用实战 实际开发中用到访问者模式的地方很少，没有必要无中生有一个故事，硬套上设计模式。Java新特性——注解——其解析原理的确用到了访问者模式。编译时Annotation解析的基本原理是：在某些代码元素上（如类型，函数，字段等）添加注解

假设 有这样一个场景：使用一个画图软件画一辆汽车，细节忽略，我们暂且只画汽车的车身、轮胎、底盘三个部分，画完之后进行上色，上色之后再进行矫正。对于画图而言，车身、底盘和轮胎组成一辆汽车，这样的结构很稳定，不会说多出一个翅膀，而不稳当的部分在于汽车的颜色和细节部分，本文要介绍的 访问者模式 ，致力于将“不稳定”的部分抽离出来，从而达到数据结构和数据操作两部分相分离的目的。 1.访问者模式 访问者模式 （Visitor Pattern), 提供一个作用于某对象结构中的各元素的操作表示，它使得可以在不改变各元素的类的前提下定义作用于这些元素的新操作。访问者模式是一种对象行为型模式。 访问者模式的主要意图是将数据结构与数据操作相分离，它解决数据结构和容易变更部分的耦合问题。UML类图是： Visitor：访问者接口，定义了数据“易变”部分的执行方法； ConcreteVisitor：访问者实现类，可扩展，不同的状态可以由不同实现类实现，符合开放-封闭原则； Element：稳定的数据结构接口； ConcreteElement：具体的实现类，这部分应该是不易变的，稳定的； ObjectStruture: 对象结构，用来分派请求。 2.代码实现 使用 画一辆汽车的例子说明。过程是： 画好车身、底盘、轮子的轮廓并上色； 对车身、底盘、轮子做微调； 定义车体部件接口

Visitor设计模式解决的问题是: 当我们需要为一组 稳定 的继承结构的各类,添加一些方法, 但是我们又不能在这些类里面修改来添加新方法, 也就是为了遵守面向对象设计中的"对扩展开放,对修改关闭"的原则. 下面我们来看一个列子: 就以老师来举例吧, 我们学院有不同的专业, 每个专业的老师上的课也不一样, 比如: 我们可视化专业, 主要是学习.NET知识, 而软件技术专业的主要学习JAVA, 所以每个专业的老师备课就不一样的, 可视化专业的老师备课.NET知识, 软件技术专业的老师备课JAVA知识,这样我们就可以构建一个这样类结构出来: 看上面的类的关系图, Teacher是一个抽象类父类, 下面继承了2个子类, 一个是VisualTeacher,可视化的老师,一个是SoftTeacher,软件技术的老师; 这个两个子类都实现了自己的备课方法,如下代码: 1 public abstract class Teacher 2 { 3 public abstract void PrepareLesson(); 4 5 } 6 7 public class VisualTeacher : Teacher 8 { 9 public override void PrepareLesson() 10 { 11 // 备课.NET 12 } 13 14 } 15 16 17 public

好代码,共享,大家看. #包含 < io流 > 元 < 型名 T > 构 访问者 { 虚 空 访问 ( T * ) = 0 ; } ; 构 访问者令牌 { 虚 ~ 访问者令牌 ( ) = 默认 ; } ; 构 动物 { 虚 整 移动 ( ) = 0 ; 虚 空 接受 ( 访问者令牌 * ) = 0 ; 虚 ~ 动物 ( ) = 默认 ; } ; 元 < 型名 T > 构 可访问 : 公 动物 { 空 接受 ( 访问者令牌 * v ) 盖 { 动转 < 访问者 < T > * > ( v ) - > 访问 ( 静转 < T * > ( 本 ) ) ; } } ; 构 狗 : 公 可访问 < 狗 > { 整 移动 ( ) 盖 { 中 4 ; } 空 游泳 ( ) { 输出 << "游泳" << 行尾 ; } } ; 构 鸟 : 公 可访问 < 鸟 > { 整 移动 ( ) 盖 { 中 2 ; } 空 飞 ( ) { 输出 << "飞" << 行尾 ; } } ; 构 鱼 : 公 可访问 < 鱼 > { 整 移动 ( ) 盖 { 中 1 ; } 空 潜水 ( ) { 输出 << "潜水" << 行尾 ; } } ; 元 < 类 . . . T > 构 多访问者 : 公 访问者令牌 , 公 访问者 < T > . . . { 用 访问者 < T > :: 访问 . . . ; } ; 用

开始 类有一个特性叫封装，如果一个类，所有的field都是private的，而且没有任何的method，那么这个类就像是四面围墙+天罗地网，没有门。看起来就是一个封闭的箱子，外面的进不来，里面的出不去，一般来说，这样的类是没用的。 现在为这个类定义一个public的method，这个method能够修改这个类的field，相当于为这个箱子开了一个门。门有了，然后访问者就有了，当一个时间段，有多个访问者进来，就可能会发生并发问题。 并发问题是个什么问题？最经典的例子就是转账，一个访问者从账户A扣取一部分金额，加到账户B上。在A账户扣取之后，B账户转入之前，数据处于不一致的状态，另一个访问者如果在这个时候访问B账户，获取的数据就是有问题的。这就是并发问题，导致这个问题的出现基于2个条件：1.访问者的操作导致数据在一段时间内是不一致的；2.可以有多个访问者同时操作。如果能够破坏其中一个条件，就可以解决并发问题了。我们的关注点是在第2个条件上。 回到那个箱子，回到那个门。我们设想为这个门加一把锁，一个访问者进了这个门，就上锁，期间其他访问者不能再进来；等进去的访问者出来，锁打开，允许另一个访问者进去。 1. 给一个代码块上锁 synchronized可以上锁、解锁。但是它本身并不是锁，它使用的锁来自于一个对象： 任何对象实例都有一把内部锁，只有一把 。

访问者模式 在GOF的《设计模式:可复用面向对象软件的基础》一书中对访问者模式是这样说的：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。访问者模式把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对自由地演化。该模式的目的是要把处理从数据结构分离出来。访问者模式让增加新的操作很容易，因为增加新的操作就意味着增加一个新的访问者。访问者模式将有关的行为集中到一个访问者对象中。现在再来说说我之前经历过的那个项目。 是基于Windows Shell开发的一个项目，在一个容器中存储了很多的Shell Items，同时定义了对Items的操作，由于项目一直都在进行后期扩展，对Items的操作在后期都需要进行扩展的；而现在的做法是，定义一个操作类，该操作类中定义了一个集合，该集合存放Items，在该操作类中扩展对应的操作方法。现在想想如果使用访问者模式也是可以的，由于Items集合是固定的，当需要扩展集合的操作时，只需要添加对应的访问者即可。 UML类图 Visitor（访问者）：为该对象结构中ConcreteElement的每一个类声明一个Visit操作。该操作的名字和特征标识了发送Visit请求给该访问者的那个类。这使得访问者可以确定正被访问元素的具体的类。这样访问者就可以通过该元素的特定接口直接访问它。