Question

我遇到了一个问题，我试图用非常明显的解决方案来解决（至少对我而言）。假设我有一个简单的类

class Foo {
  private:
    int x, y, z;
  public:
    Foo(int x, int y, int z) : x(x), y(y), z(z) {}
}

属性x，y，z也有公共getter和setter。

我有一个封装Foo矢量Item的类，它初始化它们并给它们提供默认值等等......

现在Store正被第三个班级Processor修改。基本上我试图实现的行为如下：

Processor有一个std :: function的向量，其中包含指向Store的不同成员的指针，例如ChangeItemSpecs()或ChangeItemSourcing()。它是一个循环并重复调用的列表。
Processor在调用函数后检查Store，如果它们是＆＃34; good＆＃34;变化。例如，如果商店的总价值增加，或者商店的运营成本较低。我可能有不同的处理器来分析一个模型，该模型包含指向不同成员Store的指针。或者也许是同样的事情，但只是进行不同的分析。
如果更改不利，Processor应该＆＃34;回滚＆＃34;所做的改变。 这就是我在设计中苦苦挣扎的地方

最初，我正在考虑以某种方式获取将要更改的项目的指针和索引，并Processor制作它们的副本，因为Item几乎只比POD高出一步类。如果建议的更改不合适，Processor会将修改后的Item替换为原始Item副本。但这非常低效，因为我有一个非常大的数据集。

我的问题归结为：我想要一种通用的方式来存储关于Item（或一堆项目）的先验信息，以便我可以在Processor没有＆{ ＃39; t喜欢这种变化。

我考虑过创建一个名为Change的对象，其中Store可以注册处理和回滚更改的成员，然后让Processor存储Change个对象的数组。变更将有一个名为＆＃34; proposedChange＆＃34;和＆＃34;回滚＆＃34;改变（是否有一个不同的范例，它适合于＆＃34; acceptchange＆＃34;？）。然后Processor将在每次迭代时循环遍历每个Change项并执行其操作。但这并没有真正解决管理回滚信息的问题。只是另一种抽象......

非常感谢任何帮助。我是否错误地接近了这个问题？是否有不同的方式来看待它？我该如何设计呢？我不需要代码，除非它采用了C ++的一些深奥功能，或者非常先进 - 我只需要指导如何设计一个有效的系统。

其他评论：

表现是关键。如果不是每个商店Items，有可能有数十万。因此，为什么我认为我首先提出的复制方法太过于受到性能影响。
它应该经得起简单的并行化。这意味着在Model中存储状态信息可能不是一个好主意（或者是它？）。我想非常简单地并行化Processor中的迭代。如果我忽略了某些事情并且这变得非常复杂，那么我们现在就可以忘记这一点。

提前致谢！

Answer 1

我认为使用记录修改所带来的更改的Change对象的方法是一个很好的方向。

实际上，这是一种非常实用的方法，根据经验，并行就像功能一样。我不认为我完全理解你的模型，但为了简单起见，我们假设我们只有一个项目列表，可以插入或删除项目。然后归结为两个简单的转换。

f _ins（ L ， i ， X ） - 插入项目位于 i 的 X 进入列表 L
f _del（ L ， i ） - 删除位置 i 从列表 L

如您所见， f _ins ^-1 = f _del反之亦然。

使用composition我们可以构建任意复杂的更改。另请注意，通常（ f ₁∘ f ₂）^-1 = < i> f ₂ ^-1∘ f ₁ ^-1

因此，一旦您确定了构成模型更改的基本操作并为每个操作定义了逆操作，就可以通过相反的顺序应用逆操作来组合复杂的更改并回滚。

如果您喜欢设计模式，那么这就是 Command 模式。转换对象的优点在于它们通常非常简单，可以根据需要进行序列化和存储。

如果您想并行尝试多项更改，您甚至可以使用装饰器模式更进一步。您不必将更改直接应用于模型，而是创建一个装饰模型，以便在每次调用接口函数时应用更改。因此，例如，如果使用在 L 中的位置 i 处插入项 X 的转换来修饰模型，则装饰器仅存储此信息。然后，如果发出对 j -th元素的请求，则装饰器检查 j ＆lt; i 如果是这样，只需转发到现有模型即可。否则，如果 j ＆gt; i ，它转发给要求元素 j 的模型 - 1.最后，如果 j = i ，它返回自己的元素 X 。每个装饰器只需要存储转换，而不是整个模型。您可以将装饰器堆叠在一起以共享相同的更改。如果您发现变化情况更糟，只需处置装饰器，没有人会注意到。如果您真的喜欢更改，它可以应用于模型，但在这种情况下，所有其他装饰器都将失效，因此在并发应用程序中不应经常发生。

动态调用向量中所有对象的C ++类成员

1 个答案: