访客模式选择 [英] Visitor Pattern Choices

查看:108
本文介绍了访客模式选择的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

对此可能没有正确或错误的答案,但我想要问

让我放心吧。好吧,假设你有一个对象层次结构(例如,从GOF书中获得Lexi中的雕文
)并且你想使用访问者

模式。所以我们在基类字形中放置一个accept方法,然后用

进行创建访问者层次结构。接受签名看起来像

这样


无法雕文::接受(访客& v);


访问者层次结构将有一个Vistor基类,对于每种不同类型的Glyph都有一个

访问方法,所以说如果我们有一个

AssignnentNode和VariableNode将会有两个方法


void visit(AssignnentNode& n);

void visit(VariableNode& n);


并且在每个具体的访问者中,我们实现这些方法以表现我们希望的b $ b b。到目前为止一直这么好......


想象一下,你想到20种不同类型的操作,你喜欢在你的对象结构上执行
并且你喜欢使用访客模式

来做这件事。所以你创建了20个不同的类,每个类实现了

访问者界面。


我们应该从访问者基类继承所有这20个类吗?如果

所以这意味着对象结构中的单个Accept方法足以满足所有这些操作的需要。


应该我们创建了不同的单独的访问者层次结构,每个层次结构都是

自己的接受方法,但是将相关的操作分组在一起?


我们应该走到一半并创建这些组但是所有继承自

普通访客基类。这种方法也需要一个

接受方法。


目前我倾向于最后一种方法,但我担心

具有单个访问者层次结构已将20个操作绑定在一起(一些与b $ b相关而另一些则无关)。层次结构更浓密更深刻

但它仍然是


开发者社区对此主题的总体感觉是什么?

Probably there is no right or wrong answer to this but I thought to ask
to put my mind at rest. Ok lets say you have a object hierarchy (eg.
the Glyph in Lexi from GOF book) and you want to use the visitor
pattern. So we place an accept method in the the base class glyph and
procede to create the visitor hierarchy. The accept signature will look
like this

void Glyph::Accept(Visitor& v);

The Visitor hierarchy will have a Vistor base class that will have a
visit method for each different type of Glyph so say if we have an
AssignnentNode and VariableNode there will be two methods

void visit(AssignnentNode& n);
void visit(VariableNode & n);

and in each concrete visitor we implement these methods to behave as we
wish. So far so good...

Imagine you think of 20 different types of operations that you like to
perform on your object structure and u like to use the Visitor pattern
to do this. So you create 20 different classes each implementing the
visitor interface.

Should we inherit all these 20 classes from our visitor base class? If
so this means a single Accept method in the object structure is
sufficent to serve all of these operations.

Should we create different and separate visitor hierarchies each with
its own accept method but grouping related operations together?

Should we go half way and create these groups but all inherit from a
common visitor base class. This approach also will require a single
accept method.

Currently I am leaning towards the last approach but I am worried that
having a single visitor hierarchy has tied 20 operations together (some
related while others unrelated). The hierarchy is more bushy and deeper
but it still

Whats the general feeling of the developer community on this topic?

推荐答案

我没有完全理解你说的话。

我无法理解课程层次结构。


但是我能够理解你要超载访问

函数20次。这不是真的需要而且非常痛苦。


使用模板而不是。


如果您了解模板,您将了解需要对于可重用性,

特别是当你想重叠数百次时。您将

只创建一个函数,并将其用于任何类型的数据类型

(包括用户定义的)

I did not completly understand what you said.
I am not able to understand the class hierarchy.

but I am able to understand that you want to overload the visit
function 20 times. That is not really needed and it is very painful.

Use templates instead of that.

If you know templates, you will understand need for reusability,
especially when you want to overlaod several hundred times. You will
create only one function and you use it for any kind of datatype
(including user-defined)

< br <>

Murali Krishna写道:
Murali Krishna wrote:
我没有完全理解你说的话。
我无法理解类的层次结构。
I did not completly understand what you said.
I am not able to understand the class hierarchy.




请引用你要回复的信息,并阅读

访客模式。

Jonathan



Please quote the message you are answering to and do read about the
visitor pattern.
Jonathan


Merlin写道:
我们应该走到一半并创建这些组,但所有组都继承自
公共访问者基类。这种方法也需要单一的接受方法。

目前我倾向于采用最后一种方法,但我担心单一访客层次结构已经捆绑了20次操作
一起(一些相关而另一些不相关)。层次结构更加浓密,更深层,但它仍然是开发者社区对这一主题的总体感受?
Should we go half way and create these groups but all inherit from a
common visitor base class. This approach also will require a single
accept method.

Currently I am leaning towards the last approach but I am worried
that having a single visitor hierarchy has tied 20 operations
together (some related while others unrelated). The hierarchy is more
bushy and deeper but it still

Whats the general feeling of the developer community on this topic?




我不知道这里有什么问题以及你在问什么。

如果我理解正确,你会尝试让不同的访问者实现不同的算法。我是对的吗?


如果我是,那么我会尝试将访客模式与策略模式相结合。

我不确定是否可能冗余在这里可能是其他人

想评论它。


换句话说,如果你在你面前有GoF,请看看

策略(第315页)并且示例中有两个类:组合和

Compositor。我的想法是让一个访问者使用

不同的策略。对任何人都有感觉吗?我也很好奇:-)

干杯

-

Mateusz ?? oskot
http://mateusz.loskot.net


这篇关于访客模式选择的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆