《设计模式》笔记: 访问者模式

这篇博客探讨了在C++中如何使用访问者模式来解耦类结构和类操作。通过引入Operator类,利用双委派技术,使得Element类无需改动就能添加新的操作。此外,介绍了如何通过ObjectStructure容器类来管理复杂的数据结构,实现更灵活的代码维护。

1.简介

目的是封装一些施加于某种数据结构元素之上的操作。一旦这些操作需要修改的话,接受这个操作的数据结构则可以保持不变。

2.问题的起源:


我们有如上图的类结构。现在的需求是:

Element和ConcreteElementA,ConcreteElementB的类结构是很稳定的。但是要经常更改类操作Operate*()。比如说增加一个Operate3,删除Operate1等等。这样的话,子类和父类都要更改。


3.解决办法:解耦类结构和类操作

把类操作封装成另一族类Operator。将原来的类操作视为是Operator(也就是Visitor)对Element对象的访问。Element现在只需定义一个类操作。就是Accept这个神奇的方法。为什么说Accept神奇呢,因为它用到了双委派(double-dispatch)技术。


     对于C++这个原生只支持单委派(single-dispatch)的语言而言:其一个多态方法在编译的时候选择哪种实现只取决于该方法的一个参数的类型,这个参数就成类方法隐藏的this指针。而支持双委派的语言中,类方法具体实现的选择可以取决于类方法的两个参数。

    我们看accept这个方法,它实际上有两个参数,一个是element *this指针,另一个是operator *op。编译器会根据this的类型选择ConcreteElementA的accept实现或是ConcreteElementB的accept实现(这决定了op调用哪个方法函数VisitConcreteElement*)。但accept的实现也取决于op的类型,编译器不能为我们做选择,而我们要显式地对opertor类再做一次single-dispatch实现这一点:

{ op->VisistConcreteElement*(this); }

    可见,accept的双委派实际上是由两个单委派制造的“伪双委派”

 

  再看是如何解耦的:

   原来的函数调用:ConcreteElementX.operateN

   现在的函数调用:OperatorN.vistiConcreteElementX(ConcreteElementX*  this) <=> ConcreteElementX.accept(OperatorN *op)

   现在,可以在完全不用更改ConcreteElement*类的前提下更改对其的操作。

 

4.用一个容器类来包含复杂的数据结构

实际中,数据结构不仅是一两个简单的ConcreteElement对象,而可能是多个不同的ConcreteElement的组合(Composite模式)。所以有必要用容器类来封装这些结构。这使得ObjectStructure类有了必要。通常ObjectStructure只是一个vector<element *>或是list<element *>的一层简单封装即可。它也有一个Accept方法,就是枚举容器中每个ConcreElement的Accept操作。

最后献上访问者模式的UML图:

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值