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

Question

我有一个问题，我正在尝试用一个非常不明显的解决方案（至少对我而言）来解决。假设我有一个简单的 class

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

属性 x、y、z 也有 public getter 和 setter。

我有一个 class 封装了 Foo 的向量，Item，它初始化它们并给它们默认值，等等...

现在 Store 正在被第三个 class Processor 修改。本质上，我要实现的行为如下：

Processor 有一个向量 std::function，它包含指向 Store 的不同成员的指针，例如 ChangeItemSpecs() 或 ChangeItemSourcing()。这是一个循环遍历并重复调用的列表。
Processor 在调用函数后检查 Store，如果它们是 "good" 变化。例如，如果商店的总价值增加了，或者商店的运营成本降低了。我可能有不同的处理器来分析一个模型，该模型包含指向 Store 的不同成员的指针，这些成员做不同的事情。或者可能是相同的东西，只是运行不同的分析。
如果更改不受欢迎，Processor 应该"roll back" 进行更改。 这就是我在设计上苦苦挣扎的地方

最初我想以某种方式获取将要更改的项目的指针和索引，并让 Processor 复制它们，因为 Item 几乎只是上面的一步一个 POD class。如果提议的更改不受欢迎，Processor 将用原始 Item 副本替换修改后的 Item。但这是非常低效的，因为我有一个非常大的数据集。

我的问题归结为：我想要一种通用的方式来存储关于 Item（或一堆项目）的先验信息，如果 Processor 不喜欢这种变化。

我考虑制作一个名为 Change 的对象，其中 Store 可以注册处理和回滚更改的成员，然后让 Processor 存储一个 Change 的数组对象。 Change 将有一个名为 "proposeChange" 和 "Rollback" 的成员 change（是否有不同的范例适合 "acceptchange" ？）。然后 Processor 会在每次迭代中简单地遍历每个 Change 项目并执行它的操作。但这并没有真正解决管理回滚信息的问题。只是另一个抽象...

非常感谢任何帮助。我是否错误地处理了这个问题？有不同的看待方式吗？我该如何设计呢？我真的不需要代码，除非它使用了 C++ 的一些深奥的特性，或者非常先进——我只需要有关如何设计高效系统的指导。

其他评论：

性能是关键。每个“商店”中可能有数十万甚至更多 Items。因此，为什么我认为我首先建议的复制方法对性能影响太大。
它应该经得起简单的并行化。这意味着在模型中存储状态信息可能不是一个好主意（或者是？）。我想非常简单地并行化 Processor 中的迭代。如果我忽略了某些东西并且这变得非常复杂，那么我们现在可以忘记它。

提前致谢！

Answer 1

我认为您使用 Change 对象记录修改引起的变化的方法是一个很好的方向。

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

f_ins(L,i, X) — 将位置 X 的项目 X 插入列表 L
f_del(L, i) — 从列表 L

i

如你所见，f_ins⁻¹ = f_del 反之亦然。

使用composition我们可以构建任意复杂的变化。还要注意一般 (f₁ ∘ f₂ )⁻¹ = f₂⁻¹ ∘ f₁⁻¹.

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

如果您喜欢设计模式，这就是 Command 模式。转换对象的好处是它们通常非常简单，如果需要可以序列化和存储。

如果您想并行尝试多个更改，您甚至可以使用 Decorator 模式更进一步。您不必将更改直接应用到模型，而是创建一个装饰模型，在每次调用接口函数时应用更改。因此，例如，如果您使用在 L[=106= 中的 i 位置插入项目 X 的转换来装饰模型]，装饰器只存储这些信息。然后，如果请求第 j 个元素，装饰器检查是否 j < i 如果是，则简单地转发到现有模型。否则，如果 j > i，它转发到模型请求元素 j – 1。最后, 如果 j = i, 它 returns 它自己的元素 X.每个装饰器只需要存储转换，而不是整个模型。您可以将装饰器堆叠在一起以共享相同的更改。如果您发现更改变得更糟，只需处理掉装饰器，就不会有人注意到了。如果您真的喜欢更改，可以将其应用于模型，但在这种情况下，所有其他装饰器都将失效，因此在并发应用程序中不应经常发生这种情况。

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

Dynamically call C++ class members for all objects in a vector

c++

oop

c++11