锁定老帖子 主题:Visitor - 访问者模式
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2008-06-23
话说有一个银行,有三个窗口,但是每个窗口的智能都是一样的,即都能办理所有的业务。因此每位来银行办理业务的人只要排队就是了,排到你了,就向业务员说明你要办理的业务,然后业务员根据你的业务选择不同的单据,打开不同的账本。……。
业务员此时典型的工作流程是: if (service instanceof Saving){ //存款 ...... }else if (service instanceof Draw){ //提款 ...... }else if (service instanceof Fund){ //基金 ...... } ...... 于是每位业务员的桌面总是塞得满满的,更重要的是大量的时间都花在受理不同业务之间的切换,使得效率很低。
有没有方法能够使得业务员的工作效率提高呢?银行经理苦思冥想了半天,终于想出了一个好办法。他让每个窗口各负责一个业务,同时委任了一位访问者(Visitor),负责在客户进门时,询问他要办理什么业务,告诉他应该去哪个窗口办理。这样,每个窗口的业务员就只负责一项业务,减少了在不同业务间切换的时间耗费 ,效率大大提高。更重要的是,当某一项业务的处理流程发生变更时,不需要同时麻烦三个窗口的业务员,而只需要让处理这项业务的业务员进行修改就可以了 。
下面就来定义Visitor类,这个Visitor类实际上还办含了不同窗口受理员的职责,可以认为是银行的受理反应机制吧。
public class Visitor { public void process(Service service){ // 默认业务 } public void process(Saving service){ // 存款 } public void process(Draw service){ // 提款 } public void process(Fund service){ // 基金 } } 接着我们定义业务基类。
public class Service { public void accept(Visitor visitor) { visitor.process(this); } }
不同的业务类。 public class Saving extends Service { //各种业务处理流程 } public class Draw extends Service { //各种业务处理流程 } public class fund extends Service { //各种业务处理流程 } 好了,接下来就是我们的访问者与到来的客户之间的交互了。 public class Client { public static void main(String[] args) { Service s1 = new Saving(); Service s2 = new Draw(); Service s3 = new Fund(); Visitor visitor = new Visitor(); s1.accept(visitor); s2.accept(visitor); s3.accept(visitor); } } 后话:专门设定一个访问者的职位还是有点多余,于是后来银行经理请设备公司做了一个排号机来代替访问者。
总结 Visitor模式实际上是利用的语言本身的特性,见Vistor类的各个函数,通过不同的参数来自动查找相应的处理函数。
采用Visitor的好处如上面说到的那样,当需要改变其中一项业务的处理时,不需要每个地方都进行修改,而只需要改动Visitor类中相应的处理函数就可以了。也就是说它适合于业务处理时常发生变动的情况。
当然,Visitor也有它自身的限制。它不适合于业务数量的经常变化,因为一旦新增或删除一些Service时,需要对visitor进行相应的增删。也就是说具体Service与Visitor是耦合的。 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2008-06-23
比喻很形象,受教育了! 想问下,现实中,什么场景会用到 观察者模式呢?
|
|
返回顶楼 | |
发表时间:2008-06-23
是访问者模式啊
|
|
返回顶楼 | |
发表时间:2008-06-23
duooluu 写道 是访问者模式啊
不要意思,是我弄错了。写着访问者居然想着观察者,可见我不够专心。。。 修改过来了。 |
|
返回顶楼 | |
发表时间:2008-06-23
qianlei007 写道 比喻很形象,受教育了! 想问下,现实中,什么场景会用到 观察者模式呢?
我结论上说得很清楚: 引用 它适合于业务处理时常发生变动的情况
这个模式的由来是文档的打印处理。由于每一行的文本都有各自的特性,因此如果在处理每一行时都要进行判断,那就是一大堆的“if-else”了。另外,当一个函数达到几百行的规模,相信谁见到都会头疼的,包括原作者。因此就提出了Visitor,由它作为访问者深入到业务类里“访问”各个具体业务,并作出正确的处理。 其实用到Visitor模式的地方很多,只要你设立了Service处理中心,用于处理各种不同的Service时,你就可以使用Visitor模式。 |
|
返回顶楼 | |
发表时间:2008-06-23
就是利用的多态啊 好像没啥特别的诶!!
|
|
返回顶楼 | |
发表时间:2008-08-11
是啊,就是多态
|
|
返回顶楼 | |
发表时间:2008-08-12
lintomny 写道
话说有一个银行,有三个窗口,但是每个窗口的智能都是一样的,即都能办理所有的业务。因此每位来银行办理业务的人只要排队就是了,排到你了,就向业务员说明你要办理的业务,然后业务员根据你的业务选择不同的单据,打开不同的账本。……。
业务员此时典型的工作流程是: if (service instanceof Saving){ //存款 ...... }else if (service instanceof Draw){ //提款 ...... }else if (service instanceof Fund){ //基金 ...... } ...... 于是每位业务员的桌面总是塞得满满的,更重要的是大量的时间都花在受理不同业务之间的切换,使得效率很低。
有没有方法能够使得业务员的工作效率提高呢?银行经理苦思冥想了半天,终于想出了一个好办法。他让每个窗口各负责一个业务,同时委任了一位访问者(Visitor),负责在客户进门时,询问他要办理什么业务,告诉他应该去哪个窗口办理。这样,每个窗口的业务员就只负责一项业务,减少了在不同业务间切换的时间耗费 ,效率大大提高。更重要的是,当某一项业务的处理流程发生变更时,不需要同时麻烦三个窗口的业务员,而只需要让处理这项业务的业务员进行修改就可以了 。
下面就来定义Visitor类,这个Visitor类实际上还办含了不同窗口受理员的职责,可以认为是银行的受理反应机制吧。
public class Visitor { public void process(Service service){ // 默认业务 } public void process(Saving service){ // 存款 } public void process(Draw service){ // 提款 } public void process(Fund service){ // 基金 } } 接着我们定义业务基类。
public class Service { public void accept(Visitor visitor) { visitor.process(this); } }
不同的业务类。 public class Saving extends Service { //各种业务处理流程 } public class Draw extends Service { //各种业务处理流程 } public class fund extends Service { //各种业务处理流程 } 好了,接下来就是我们的访问者与到来的客户之间的交互了。 public class Client { public static void main(String[] args) { Service s1 = new Saving(); Service s2 = new Draw(); Service s3 = new Fund(); Visitor visitor = new Visitor(); s1.accept(visitor); s2.accept(visitor); s3.accept(visitor); } } 后话:专门设定一个访问者的职位还是有点多余,于是后来银行经理请设备公司做了一个排号机来代替访问者。
总结 Visitor模式实际上是利用的语言本身的特性,见Vistor类的各个函数,通过不同的参数来自动查找相应的处理函数。
采用Visitor的好处如上面说到的那样,当需要改变其中一项业务的处理时,不需要每个地方都进行修改,而只需要改动Visitor类中相应的处理函数就可以了。也就是说它适合于业务处理时常发生变动的情况。
当然,Visitor也有它自身的限制。它不适合于业务数量的经常变化,因为一旦新增或删除一些Service时,需要对visitor进行相应的增删。也就是说具体Service与Visitor是耦合的。
|
|
返回顶楼 | |
发表时间:2008-08-12
总结的好:
Visitor模式实际上是利用的语言本身的特性,见Vistor类的各个函数,通过不同的参数来自动查找相应的处理函数。 if (service instanceof Saving){ //存款 ...... }else if (service instanceof Draw){ //提款 ...... }else if (service instanceof Fund){ //基金 ...... } 转化为 public void process(Saving service){ // 存款 } public void process(Draw service){ // 提款 } public void process(Fund service){ // 基金 } if..else 总是代表变化的部分,将变化的部分封装,这里封装到方法. |
|
返回顶楼 | |
发表时间:2008-08-12
访问者模式可以认为是Collection的一个变种,我们知道collection只能装同类型的对象,如果想装不同类型的数据访问起来就比较麻烦 要用到楼主所说的
# if (service instanceof Saving){ # //存款 # ...... # }else if (service instanceof Draw){ # //提款 # ...... # }else if (service instanceof Fund){ # //基金 # ...... # } 非常麻烦。 visitor模式只是让每个要访问的类型implements Visitable而已 public interface Visitable{ public void accept(Visitor visitor); } 这样Collection在处理的时候就可以统一的访问Visitable的accept方法 就是这么简单!具体的情况可能会去调整 但其思路就是这样的 |
|
返回顶楼 | |