问题标签 [policy-based-design]

在我的工作中，我有很多内部函数调用的循环；性能在这里很关键，虚函数调用的开销是不可接受的，所以我尝试通过使用 CRTP 来避免动态多态性，如下所示：

另外：实际使用 CRTP 类的正确方法是什么？现在我需要实际类型依赖于运行时用户选项，通常具有抽象基类/策略模式的动态多态性将是正确的设计，但我买不起虚函数调用。一种方法似乎是使用一些分支：

但这似乎是一个糟糕的设计。在此处将其作为模板参数传递（或使用基于策略的设计）似乎是一种选择：

但是这里的 worker 只在 if 分支中有作用域，我需要它的生命周期与程序一样长。此外，相关的用户选项可能会指定 4+“策略”，每个选项都有几个选项（比如 4），所以看起来你很快就会遇到一个令人讨厌的问题，模板类可能会占用 4*4* 中的 1 个4*4模板组合。

此外，将循环逻辑移动到类型中也不是一种选择——如果是虚拟函数调用开销可以忽略不计，我会使用正常的多态性。循环的实际控制可能相当复杂，并且会在运行时发生变化。

这是否表明我应该尝试构建一个自定义迭代器并将其作为函数参数传递并使用正常的多态性，还是会产生类似的开销？

在运行时选择类而不求助于抽象基类的指针有什么好的设计？

祝大家圣诞快乐！

我正在学习静态多态性，并且正在阅读 Andrei Alexandrescu 关于基于策略的设计的优秀书籍。我在我的代码中遇到了以下内容：我有接口Interface指定Foo必须存在该方法。该接口将由 class 实现Impl。我有以下两个选择：

1）动态多态性

2) 静态多态性

在这种情况下使用静态多态是否有意义？与第一种方法相比，第二种方法有什么好处吗？接口只指定了一些方法的存在，并且它的机制对于不同的实现是相同的——所以不太像书中描述的案例，所以我觉得我可能只是把事情复杂化了。

更新：我在运行时不需要多态行为；正确的实现在编译时是已知的。

我正在尝试使用基于策略的设计来概括我的类，并且 gcc 似乎没有看到在基类中实现的纯虚函数的实现。这是一个例子：

我得到的错误是：

有两个问题我不太明白：

1. 即使函数签名完全相同，编译器似乎也不认为AccessPolicy< ReturnType >::implementation< DataClass >...是一个实现 。AccessPolicy< ReturnType >::interface...
2. 即使它们都有不同的参数，编译器也无法解析我正在调用的 operator[]，而我显然正在调用 size_t （数字不能隐式转换为字符串）。

任何想法为什么会发生这种情况？

我的猜测是，即使我直接从“接口”和“实现”继承，成员函数也会以某种方式最终出现在不同的命名空间中。如果这是正确的，我该如何解决这个问题？

编辑：根据请求添加了上面的示例，去掉了模板

我现在的类设计是这样的（我已经复制了类层次结构和函数调用。）：

我正在尝试用一些基于模板的策略工厂来替换这个逻辑。我之前没有基于 plicly 设计过任何课程 有人可以建议设计应该如何？

在Modern C++ Design: Generic Programming and Design Patterns AppliedAndrei Alexandrescu 中，提倡保护策略的析构函数：

因为析构函数是受保护的，只有派生类才能销毁策略对象，所以外人不可能对指向策略类的指针应用 delete。然而，析构函数不是虚拟的，因此没有大小或速度开销

但后来，他写了以下关于政策兼容性的段落：

如您所见，您在实施策略之间的转换方面具有双向灵活性。您可以在左侧实现转换构造函数，也可以在右侧实现转换运算符。

假设我们有 2 个策略：

如何在不构造 First 类型的临时对象的情况下创建从策略 Second 到 Policy First 的转换运算符？

考虑一个基于策略的智能指针类 Ptr，它只有一个策略可以防止在 NULL 状态下（以某种方式）取消引用它。让我们考虑 2 种此类策略：

• NotNull
• NoChecking

由于该NotNull策略更具限制性，我们希望允许从Ptr< T, NoChecking >到的隐式转换Ptr< T, NotNull >，但不允许相反方向的转换。为了安全起见，那个必须是明确的。请看下面的实现：

活生生的例子

上面的代码在双向隐式转换时失败，这意味着std::is_convertible即使类具有兼容的构造函数也会失败。问题是：

1. 构造函数重载不能仅仅通过显式关键字来区分，因此我们需要在宿主类中显式构造函数和隐式转换运算符（反之亦然）。
2. 显式构造函数更好，因为任何构造函数都会从初始化列表中调用显式构造函数，即使它本身是隐式的。
3. 隐式转换运算符无法创建策略类型的对象，因为它们的析构函数受到保护。这就是为什么std::is_convertible它不应该失败的原因，这也是为什么我们不能boost::implicit_cast< const target_policy& >( *this )在转换运算符中使用类似的东西，因为它会创建一个临时的策略对象，这是被禁止的。

至于我认为不是最优的明显解决方案：

1. 将策略析构函数公开- 并在将 Ptr* 转换为 policy* 并删除它时冒 UB 风险？这在所提供的示例中不太可能，但在实际应用中是可能的。
2. 将析构函数设为公共并使用受保护的继承——我需要公共继承提供的丰富接口。

问题是：

是否存在从一种类型到另一种不创建这些类型的对象的隐式构造函数的静态测试？

或者：

从宿主类的构造函数调用策略构造函数时，如何保留隐式构造的信息？

编辑：

我刚刚意识到第二个问题可以很容易地用一个私有的、隐式标记的构造函数来回答，如下所示：

然而，这些错误不是很可读，并且我们对策略引入了不必要的要求，因此对第一个问题的回答更可取。

Andrei Alexandrescu描述的基于策略的设计给我留下了深刻的印象，Modern C++ Design并在一些轻量级程序中成功地尝试了它。现在我必须在其中编写一个真实世界的系统Python，我认为这种方法在这里非常有用。但是，我在Python. 是不推荐Python还是有更好的选择？有人可以指出一个基于策略的设计示例Python吗？我的目标是开发一个拍卖系统，我希望能够在运行时选择拍卖策略 - English、Dutch、Silent等。

由于Python和Ruby非常相似，我想一个例子Ruby也可以。

我认为解释我的问题的最好方法是使用一段代码：

基本上，一个策略可能需要访问宿主类中定义的成员，而这些成员又依赖于提供给宿主类的其他策略。

谢谢！

据我所知，mixin是先写派生类，然后可以通过模板参数将基类注入进去。

示例：http ://www.drdobbs.com/cpp/mixin-based-programming-in-c/184404445

据我所知，基于策略的设计也是如此。 http://en.wikipedia.org/wiki/Policy-based_design

它并不是说你应该从它派生，你也可以通过其他方式使用模板参数。但是，例如在 Wikipedia 基于策略的设计示例中是这样的：

我认为这与mixin相同。（相反，在 mixins 中你通常使用公共继承）

它们之间是否有任何显着差异，或者 mixin 是基于策略的设计的一个特例？

关于这个主题有相当多的信息。这更像是一个设计问题，但我会举例说明。

假设我真的想传递一个配置文件类，它决定了用户的策略。

以上内容都很好，但我们假设有很多政策需要阅读。5 似乎是一个现实世界的数字，尽管可能更多。然后，假设此配置文件将应用于数百个实例，其中 5 个策略差异很大。要启动，策略行为只能在运行时知道（从文件、数据库等读取）。这很快变得无法扩展，除非我完全错过了一些东西。

我想过做一个非类型模板类作为策略。

我认为这确实适用于我的情况，但我想知道这是否缺少基于策略的设计的要点。我在看到这一点的优点时遇到了问题，只是让 Profile 成为一个正常的结构，并根据需要将它的数据成员设置为 true/false。

想法？