问题标签 [non-virtual-interface]

非虚拟接口习惯用法描述了虚拟方法如何成为非公共定制点，而公共方法是非虚拟的，以允许基类始终控制定制点的调用方式。

这是一个优雅的习惯用法，我喜欢使用它，但是如果派生类本身就是一个基类，它是如何工作的

在 C++ 中，我经常需要NVI来获得 API 的一致性。不过，我认为它在 C# 中的使用并不多。我想知道这是否是因为 C# 作为一门语言提供了不需要 NVI 的功能？（不过，在需要的地方，我仍然在 C# 中使用 NVI。）

在 C++ 中，接口可以由其方法是纯虚拟的类来实现。

这样的类可以是库的一部分，用于描述对象应该实现哪些方法才能与库中的其他类一起工作：

：

现在我想使用 class Lib::Bar，所以我必须实现IFoo接口。

出于我的目的，我需要一个完整的相关类，所以我想使用一个保证使用 NVI 习语的常见行为的基类：

FooBase::method()非虚拟接口 (NVI )习惯用法应该拒绝派生类IFoo覆盖FooBase::method().

如果我想使用 NVI 成语，除了已经建议的 pImpl 成语之外，我还有哪些选择（感谢 space-c0wb0y）。

NVI（非虚拟接口）和模板方法模式有什么区别？

它们看起来非常相似，我读过它们基本上是相同的，并且它们之间存在细微的差异，因为 Template 更普遍。

什么是被接受的行话（如果有的话）来描述只能虚拟调用的方法以及从基础中的其他方法调用的方法？我偶尔会看到这被称为回调，但这似乎与该术语的原始定义相去甚远。我什至不确定这是否值得被称为模式，但我试图在评论我的代码时变得更加精确。谢谢您的帮助！

摘要：这似乎被称为非虚拟接口模式，是模板方法模式的一个特例。感谢尼克和史蒂文的帮助！

我想知道使用非虚拟派生时编译器会产生什么：

这里的推导是否只意味着编译时检查？还是有其他开销？

我注意到我的编译器在直接使用Point2or时会产生同样大小的对象Point<2>。我推断推导不会产生 vtable，因此，永远不会进行虚拟调用。

我错过了什么吗？

语境

我想为给定的类模板提供几个预定义的特化。我从 typedefs 开始：

唉，这会阻止客户端使用“简单”的前向声明：

然后必须编写这段相当不直观的代码：

这就是我放弃 typedef 并使用非虚拟派生的原因。不过，我想知道所有的含义是什么。

（另一种策略是在专用头文件中编写一次前向声明，à la #include <iosfwd>。）

我在头文件中遇到了以下代码：

对我来说，这意味着无论是Engine类还是从它派生的类，都必须为那些纯虚函数提供实现。但是我不认为派生类可以访问这些私有函数来重新实现它们——那么为什么要让它们成为虚拟的呢？

java final 方法和 c++ 非虚拟方法是不同还是相同？如何？

我有一个看起来像这样的层次结构：

所以问题是当我使用我的基类创建派生时如何使用这种模式调用 Execute() 。在我的情况下，我不想直接创建 Derived，因为我有多个从 Base 派生的类，并且根据某些条件我必须选择不同的派生类。

谁能帮忙？

在设计界面时，有人建议使用非虚拟界面模式。有人可以简要概述这种模式的好处是什么吗？