C++：对访客模式的怀疑

发布于 2024-10-02 13:00:18 字数 1043 浏览 4 评论 0原文

我知道什么是访客模式以及如何使用它；这个问题不是这个一个的重复问题。

我有一个库，其中放置了我编写的大部分可重用代码，并将其链接到我的大部分项目。

我经常需要向某些类添加功能，但不将这些新功能添加到库中。让我用一个真实的例子：

在这个库中，我有一个类 Shape，由 CircleShape、PolygonShape 和 CompositeShape< 继承。 /代码>。

我现在正在开发一个图形应用程序，我需要渲染这些 Shape，但不想在核心 Shape 中放置虚拟函数 render code> 类，因为我的一些使用 Shape 的项目不进行任何渲染，而其他图形项目可以使用不同的渲染引擎（我在这个项目中使用 Qt，但对于我的游戏会使用 OpenGL，因此渲染函数将需要不同的实现）。

当然，最著名的方法是使用访问者模式，但这让我产生了一些疑问：

任何库的任何类都可能需要像我的 Shape 那样进行扩展。大多数公共图书馆（几乎所有）都不提供对访客模式的任何支持；为什么？我为什么要这么做？

访问者模式是一种在 C++ 中模拟双重调度的方法。它不是 C++ 原生的，需要显式实现，使类接口更加复杂：我认为 applyVisitor 函数不应该与我的类函数处于同一级别，我看到了这个就像打破抽象。

使用 dynamic_cast 显式向上转换 Shape 成本更高，但对我来说，它看起来是一个更干净的解决方案。

那么，我该怎么办？在我的所有库类中实施双重调度？如果提供 Shape 的库不是我的，而是在互联网上找到的一些 GPL 库怎么办？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

半边脸i 2024-10-09 13:00:18

首先：“访问者模式是一种在 C++ 中模拟双重调度的方法。”这是，呃，不完全正确。实际上，双重分派是多重分派的一种形式，它是一种在 C++ 中模拟（缺失的）多方法的方法。

类层次结构上的操作是通过添加虚函数还是通过添加访问者来实现由概率决定添加类与添加操作的比较：

如果类数量的变化比操作数量更快，使用虚函数 。这是因为添加类需要修改所有访问者。
如果与操作数量相比类数量相对稳定，使用访问者。这是因为添加虚函数需要更改层次结构中的所有类。

是的，许多图书馆没有访客界面。
当我们只看上面的推理时，如果类的数量经常变化，这是正确的。也就是说，如果一个库经常发布，并且不断添加新类，那么提供访问者接口就没有多大意义，因为每次新版本带来新类时，使用该库的每个人都需要适应所有访问者。因此，如果我们只考虑上述推理，则访问者接口似乎只有在库的类层次结构中的类数量很少或从不改变的情况下才有用。

然而，对于第三方库还有另一个方面：通常，用户无法更改库中的类。也就是说，如果他们需要添加操作，他们执行此操作的唯一方法是添加访问者 - 如果库提供了挂钩让他们插入其中。
因此，如果您正在编写一个库，并且认为用户应该能够向其中添加操作，那么您需要提供一种方法，让他们将访问者插入您的库 。

回复收藏 0 原文

寻找一个思念的角度 2024-10-09 13:00:18

对我来说，这看起来不像访客模式的情况。

我建议您有一个 RenderableShape 类来聚合一个 Shape 对象，然后为每个形状创建子类。 RenderableShape 将有一个虚拟的 render 方法。

如果要支持多个渲染引擎，可以使用 RenderContext 基类来抽象绘图操作，并为每个渲染引擎创建子类，每个子类根据其渲染引擎实现绘图操作。然后，您可以让 RenderableShape::render 将 RenderContext 作为参数，并使用其抽象 API 进行绘制。

回复收藏 0 原文

雄赳赳气昂昂 2024-10-09 13:00:18

所以有一个 xxxShape 类，它以某种方式包含“驱动”渲染的信息。对于圆形，可能是中心、半径，对于正方形，可能是一些角坐标或类似的坐标。也许还有一些关于填充物和颜色的其他东西。

您不想/无法更新这些类以添加实际的渲染逻辑，我认为您不这样做的原因是有效/不可避免的。

但想必，您在类上有足够的公共访问方法来允许您获取“驾驶”信息，否则您就注定失败。

那么在这种情况下，为什么你不能只包装这些物品：

 CircleRenderer hasA Cicle, knows how to render Circles

等等。现在在渲染器类中使用访问者模式。

So there's a class xxxShape, which in some way contains information that "drives" the rendering. For Circles that might be centre, radius, for Squares some corner coordinates or some such. Maybe some other stuff about fillings and colours.

You dont't want to/cannot update those classes to add the actual rendering logic, and I think your reasons for not doing so are valid/inevitable.

But presumably, you have enough public access methods on the classes to allow you to get at the "driving" information, otherwise you are doomed.

So in which case why can you not just wrap these items:

 CircleRenderer hasA Cicle, knows how to render Circles

and so on. Now use the Visitor pattern across the Renderer classes.

回复收藏 0 原文

农村范ル 2024-10-09 13:00:18

有许多可能的解决方案，但您可以这样做，例如：启动新的层次结构，在特定的上下文中呈现形状：

// contracts:

class RenderingContext {
public: virtual void DrawLine(const Point&, const Point&) = 0; 
    // and so on...
};

class ShapeRenderer {
public: virtual void Render(RenderingContext&) = 0;
};

// implementations:

class RectangleRenderer : public ShapeRenderer {
 Rectangle& mR;

public: 
 virtual void Render(RenderingContext& pContext) {
   pContext.DrawLine(mR.GetLeftLower(), mR.GetRightLower());
   // and so on...
 }

 RectangleRenderer(Rectangle& pR) : mR(pR) {}
};

There a many possible solutions, but you could do this, for example: Start new hierarchy, which renders Shapes in a specific Context:

// contracts:

class RenderingContext {
public: virtual void DrawLine(const Point&, const Point&) = 0; 
    // and so on...
};

class ShapeRenderer {
public: virtual void Render(RenderingContext&) = 0;
};

// implementations:

class RectangleRenderer : public ShapeRenderer {
 Rectangle& mR;

public: 
 virtual void Render(RenderingContext& pContext) {
   pContext.DrawLine(mR.GetLeftLower(), mR.GetRightLower());
   // and so on...
 }

 RectangleRenderer(Rectangle& pR) : mR(pR) {}
};

回复收藏 0 原文