c++ - 为 vector 中的所有对象动态调用 C++ 类成员

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 也有公共(public)的 getter 和 setter。

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

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

• Processor 有一个 std::function vector ，它包含指向 Store 不同成员的指针，例如 ChangeItemSpecs() 或ChangeItemSourcing()。这是一个循环遍历并重复调用的列表。

• Processor 在函数被调用后检查 Store，如果它们是“好的”变化。例如，如果商店的总值(value)增加了​​，或者商店的运营成本降低了。我可能有不同的处理器来分析一个模型，该模型包含指向执行不同操作的 Store 不同成员的指针。或者也许是相同的东西，但只是运行不同的分析。

• 如果更改不利，Processor 应该“回滚”所做的更改。 这就是我在设计上苦苦挣扎的地方

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

我的问题归结为:我想要一种通用的方法来存储有关 Item(或一堆项目)的先验信息，如果 我可以更改特定属性处理器 不喜欢这种变化。

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

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

其他评论:

• 性能是关键。每个“商店”中可能有数十万个 Items。因此，为什么我认为我首先建议的复制方法对性能影响太大。

• 它应该经得起简单的并行化。这意味着在模型中存储状态信息可能不是一个好主意(或者是？)。我想非常简单地并行化 Processor 中的迭代。如果我忽略了某些东西并且这变得非常复杂，那么我们现在可以忘记它。

提前致谢!

Answer 1

我认为您的方法使用 Change记录修改导致的更改的对象是一个很好的方向。

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

• f_ins(L, i, X) — 插入项X 在位置 i 进入列表 L
• f_del(L, i) — 删除位置 i 来自列表 L

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

使用 composition我们可以构建任意复杂的更改。还要注意通常 (f₁ ∘ f₂)⁻¹ = < i>f₂⁻¹ ∘ f₁⁻¹ .

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

如果您喜欢设计模式，这就是命令 模式。转换对象的好处是它们通常非常简单，并且可以序列化并在需要时存储起来。

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