问题标签 [policy-based-design]

我正在尝试为一个项目编写遗传算法，并且很难将不同的功能分开。我一直在阅读基于策略的设计，这似乎是解决问题的方法，但我并不真正了解如何实现它。

我有一个 OptimizerHost，它继承自一个 SelectionPolicy（用于确定评估哪些解决方案）和一个 FitnessPolicy（用于确定任何给定解决方案的适用性）。问题是我无法弄清楚这两种策略如何相互通信。算法的大部分是在 SelectionPolicy 中实现的，但它仍然需要能够检查其解决方案的适用性。我唯一能想到的就是在 OptimizerHost 本身中实现 ​​SelectionPolicy 算法，这样它就会从 FitnessPolicy 继承它需要的东西。但这似乎首先忽略了使用策略的意义。我是不是误会了什么？

我需要偶尔延迟处理一个对象。然而，持有对象的线程不能延迟。

一个自然的解决方案是让一个单独的线程等待这些对象。当一个对象变得可用时，第二个线程将根据需要延迟并处理该对象。第二个线程将在信号量上休眠。当主线程有一个对象需要延迟处理时，它会将对象放入一个队列并发出信号量。

虽然这可行，但另一个程序员（或我）可能会忘记在对对象进行排队时发出信号量。我希望强制执行。

因此，我可能会创建自己的容器，它基于标准容器，但添加了回调（可能使用基于策略的设计）和内部信号量。当一个项目被添加到容器中时，它将强制运行回调函数。

但是这个功能看起来非常有用，而且非常受欢迎，我敢打赌，有人已经写了这个，可能比我在这里提出的设计更好，并解决了诸如重入之类的毛茸茸的细节。是否存在用于此的库？或者，是否有一种众所周知的技术可以获取此功能？

我有一个我正在尝试配置其行为的类。

然后稍后我有我的服务器对象本身：

我的问题是我上面的用法是我的命名错误吗？我的模板化参数实际上是策略而不是特征吗？

什么时候模板化参数是一个特征而不是一个策略？

谁能指出我广泛使用基于策略的设计的开源 C++ 项目（最好不是 lib）？

我有一堆算法和集合，并且我正在使用基于策略的设计（参见Modern C++ Design一书）来处理任意组合复杂性。这很好，但是为了防止使用指向策略的指针破坏 Host 类，1建议将策略的析构函数设为受保护。但是，如果我使算法和集合析构函数受到保护，我不能单独使用它们，而只能作为策略使用。此外，与通用工厂模式相比，我没有看到基于策略的设计的好处......

这是代码的模型：

以下是我的问题：

我正在使用策略自定义一个 Host 类的结构，当每个现实的算法都需要一个 Collection 来工作，而 Collection 被封装在 host 中时，如何才能真正丰富 Host 类的接口？

当我将基于策略的设计与通用工厂进行比较时，通用工厂不会给我带来相同的组合复杂性吗？似乎使用通用工厂更好，因为我也可以在所有可能的组合中交换元素、容器和算法，并且我仍然可以为所有策略拥有公共析构函数，这允许我以任何我想要的方式组合它们，例如元素、集合和算法的全局组合。

在我看来，一旦结构被定制，丰富的策略就会成为一个问题。即使我稍后将成员函数添加到算法中，它也可能具有与 Collection 相关的参数（例如 Collection 迭代器）：如果 Host 使用组合封装 Collection，我需要向它询问自己的成员函数的参数：

如果主机使用继承封装集合，它（至少对我来说）变得更加奇怪：

我是否完全误解了基于策略的设计（再次），我是否正确使用了这些特征？在这种情况下，通用策略模式是更好的选择吗？

假设我有一个包含成员的主机类：

我想在 p1 和 p2 中使用相同的成员：

有没有办法做到这一点？

我能想到的一种方法是通过虚拟继承从另一个包含成员的类派生p1和派生，这使得事情变得复杂。p2

另一种是将成员作为函数的参数传递给策略。像这样的东西：

另一个想法是使用 CRTP 并从策略中派生主机并从主机中派生策略，以便可以访问成员，using但这是不可能的。

更新 (1)

我对 CRTP 的尝试

我知道如何使用带有接口的 c++ 的基于策略的设计模式来实现类的实现。我不知道如何对类 mixin 做同样的事情。

如果您想从代码中挤出最后的性能，这将很有用，因为它很容易内联，并且接口的虚拟调用的“边界”不存在。

我有一个主机类，它采用两个策略，sayhello并且talk. 该策略talk是一个类模板，它本身采用例如sayhello. 问题在于（我试图用 解决这个钻石问题）sayhello::saySomething是模棱两可的。host2virtual

我该如何解决这种歧义？还是一般来说有更好的设计来解决这些问题？

例子：

我有一个roundtrip采用两个策略的类模板。只要它们不同，一切都很好，但是使用一个策略两次会导致编译错误。

例子：

如何解决？还是有更好的设计来实现相同的行为？

编辑：我在策略中添加了包装器，用户界面没有改变。您如何看待这个解决方案，它是一个干净的设计吗？

在阅读了一篇关于基于策略的设计的文章并想自己尝试一些东西之后，我花了一些时间将我曾经做过的一个记录器类重新设计为基于策略的方法。

一些代码：

根据记录器，我需要传递其他信息，例如 SimpleChannelVsLogger 中的日志通道或 FileOututter 中的日志文件的文件名。

我将参数作为常量引用传递给 LoggerImpl 的构造函数，然后将它们复制到存储在记录器类中的对象中。需要复制它们，因为生命周期扩展不能通过函数参数传递，该函数参数在将临时创建的对象绑定到 const 引用时发生（更多信息请参见：Does a const reference prolong the life of a temporary？）。

所以这里的第一件事：如果我不想使用指针，因为我在使用模板时对运行时分配不感兴趣，我想除了以上述方式复制临时创建的对象之外没有其他解决方案？

复制内容的实际问题现在来自 FileOutputter：当然不能复制一个 ofstream，那么如何复制包含流的 FileOutputter 对象？我想出了以下解决方案来克服这个问题：

不知何故，我不得不觉得这对于“简单的记录器类”来说似乎有点复杂，但是在这种情况下，这可能只是基于策略的设计方法的一个“问题”。

欢迎任何想法