1

在一个应用程序中，我有很多 dirrerent 对象，比如说：正方形、圆形等......很多不同的形状 ---> 我很抱歉这个微不足道的例子。

对于所有这些对象，我想创建一个不同类型的文档：xml、txt、html 等。（例如：我想扫描所有对象（形状）树并生成 xml 文件。

我认为的自然方法是访问者模式，我尝试过并且它有效:-) - 所有对象都有一个接受 IVisitor 接口的访问方法。- 对于我想要创建的每一种类型，我都有一个具体的访问者：（XmlVisitor、、TxtVisitor等）。每个访问者对每种对象都有一个“访问”方法。

我的疑问是......如果我有很多对象，它似乎不能很好地扩展......从逻辑的角度来看没关系，我只需在具体的访问者中添加新的形状和方法，就这样。

你怎么看 ？有可能吗？

4

3 回答 3

1

我认为您已经正确实现了访问者模式，因此您还实现了双重调度机制。如果您认为“不能很好地缩放”是在添加新形状和/或访问者的情况下需要添加一堆方法，那么它只是模式的副作用。有些人认为这种“方法爆炸”是有害的，并选择了不同的实现方式，例如使用“决策矩阵”对象。特别是对于这个例子，我认为 DD 方法是要走的路，实际上它确实可以很好地扩展，因为您在添加新要求时添加新方法（即在添加新形状或添加新形状时添加新的 visit* 方法一个新的访问者类，因为需要新的文档类型）。

高温高压

于 2012-11-06T20:04:26.147 回答
1

在我看来，您最担心的是您正在匹配许多不同类型的对象，并且担心随着越来越多的对象类型添加，性能会受到影响。不过，我认为您不必担心：访问者模式的性能不会真正受到潜在对象或访问者数量的影响，因为它基于虚拟表查找 - 传递的对象将包含指向（链接到）应该调用的方法。

因此，访问者模式虽然在间接访问方面相对昂贵，但在这方面是可扩展的。

于 2012-11-06T15:58:10.853 回答
0

我相信你有：

  1. 类层次结构（Shape在您的示例中为 s ）和
  2. 对类层次结构的操作（您的示例中exportXML的exportToHTML等）

你必须考虑什么更有可能改变——

  1. 如果类层次结构或多或少是固定的，但您希望将来添加更多操作，您应该选择访问者模式。访问者模式将允许您在不触及现有类层次结构的情况下添加更多操作（例如 JSON 导出）。

  2. OTOH，如果操作或多或少是固定的，但可以添加更多 Shape 对象，那么您应该使用常规继承。定义一个ShapeExport接口，该接口具有诸如等方法exportToXML。exportToHTML让所有形状实现该接口。现在您可以添加实现相同接口的新形状，而无需触及现有代码。

于 2012-11-07T08:10:45.827 回答