c ++标准实践：虚拟接口类与模板

Question

我必须就泛化与多态性做出决定。

这个场景是标准的：我想让我的整体相互依赖 代码更加模块化，清洁和可扩展。 它仍然处于可以改变设计原则的阶段， 而且，正如我所看到的，非常可取。

我会介绍纯虚基类（接口）或模板吗？

我了解有关模板选项的基础知识： 减少间接，更好的性能，更多的编译 但 没有后期绑定，等等。

stl不使用太多（或没有？）继承，而boost也没有。 但我认为这些都是非常小的基本工具 程序员编写2行代码。

我认为继承和后期绑定方法更为明智 插件样式的大块代码和功能应该可以互换， 部署后甚至在运行时期间可更新等。

我的情景有点介于两者之间。

我不需要在运行时动态交换代码片段，编译时间很好。 通常它也是一个非常核心且经常使用的功能， 它在逻辑上不能分成大块。

这让我倾向于模板解决方案。 对我来说，它看起来也更清洁了。

是否有任何重大不良影响，界面仍然是这样的 去？他们什么时候不是？ 哪个更符合标准的c ++风格？

我知道这接近于主观，但我真的很感兴趣 一些经验。我没有Scott Meyers有效C ++的副本 所以我寄希望于你们：）

Answer 1

你基本上是正确的，当允许在运行时更改类型时（例如在插件架构中），动态多态（继承，虚拟）通常是正确的选择。如果类型只应在编译时更改，则静态多态（模板）是更好的选择。

模板的唯一潜在缺点是1）它们通常必须在头文件中定义（这意味着更多的代码被#included），这通常会导致编译时间变慢。

但从设计角度来看，我无法在可能的情况下使用模板时遇到任何问题。

  

符合标准c ++的更多内容   风格？

取决于“标准C ++风格”。 C ++标准库使用了一切。 STL使用模板来处理所有事情，稍微旧的IOStreams库使用继承和虚函数，当然，从C继承的库函数也不使用。

现在，模板是迄今为止最受欢迎的选择，我不得不说这是最“标准”的方法。

Answer 2

经典面向对象多态的属性：

• 对象在运行时绑定;这更灵活，但在运行时也消耗更多资源（CPU）
• 强大的打字带来了更多的类型安全性，但是dynamic_cast的需要（以及它可能会炸成客户的脸）可能很容易弥补这一点
• 可能更广为人知和理解，但“经典”的深层继承等级对我来说似乎很可怕

模板编译时多态的属性：

• 编译时绑定允许更积极的优化，但会阻止运行时灵活性
• duck-typing似乎更尴尬，但失败通常是编译时失败
• 有时可能更难阅读和理解;没有概念，编译器诊断有时可能会变得令人愤怒

请注意，无需任何一个决定。你可以自由地混合和混合它们（以及许多其他习语和范例）。通常，这会导致非常令人印象深刻（和富有表现力）的代码。 （例如，请参阅类型擦除等内容。）为了通过巧妙地混合范例来了解可能的内容，您可能希望浏览Alexandrescu的“现代C ++设计”。

Answer 3

这是一种虚假的反对意见。是的，继承和虚函数的主要用途是iostreams，它们非常陈旧，并且以与std库的其余部分完全不同的风格编写。

但许多“最酷”的现代C ++库（如boost）确实利用了运行时多态性，他们只是使用模板来使它更方便使用。

boost::any和std::tr1::function（以前也来自提升）就是很好的例子。

它们都是单项容器，其具体类型在编译时是未知的（对any来说尤其明显，因为它有自己的动态转换运算符来获取值）。 / p>

Answer 4

在我的盘子上有更多经验之后，模板中有一些我不喜欢的东西： 将模板元编程视为可用语言是不合格的：

• 可读性：括号太多，非语言强制执行（因此误用）太多
• 对于经历编程语言常规演变的人来说，模板难以理解且难以理解（只需看看boost bgl）
• 有时感觉有人试图用awk编写c ++代码生成器。
• 编译器错误消息是cl（完全）ed crap
• 需要太多的黑客攻击（其中大部分都是在c ++ 0x中修复）以获得一些基本的“语言”功能。
• 实施文件中没有模板导致只有标题库（这是一把非常双面的剑）
• 通常的IDE代码完成功能对模板没什么帮助。
• 在MPL中做大事似乎“讨厌”，找不到另一个词。模板化代码的每一行都会对该模板类型产生约束，这些约束以文本替换方式强制执行。继承层次结构中存在固有的语义，模板结构中没有任何内容。这就像一切都是空的*，编译器试图告诉你是否会出现段错误。

所有这些，我在基本实用程序和库上使用它非常成功。用它编写高级功能或硬件相关的东西，似乎并不适合我。 意思是我模板化我的构建块，但用经典的方式构建房子。

Answer 5

从我的角度来看，这是你最擅长的。如果您有更多OO使用OO的经验。如果您有更多使用仿制药的经验。

这两种技术都有一些等效的模式，这些模式对很多你可以使用的东西都意味着。 OO中的EG策略与泛型中的策略或OO中的模板方法与泛型中的通常重复模板模式。

如果您计划的重构生产代码已经有效，但结构有点臭。不要以它为借口来使用一些新的设计技术，因为在一两年内，一旦你更好地理解了这种技术，你可能会后悔如何重构你的代码。在学习它们时应用技术时，很容易引入新的不灵活性。如果您不熟练掌握如何知道自己正在改进设计而不是在代码中构建大型阴茎符号，那么目的是改进现有代码的设计。

就我个人而言，我更擅长OO并倾向于支持它，因为我知道我可以制作易于理解的清洁设计，并且大多数人都可以改变。我正确的大多数通用代码旨在与其他通用代码接口，例如编写迭代器或算法的通用函数。

Answer 6

我在我的大型代码库中使用它们。当在编译时知道类型时，我用模板设计它，当它只在运行时知道时，我使用虚函数。我发现虚拟函数更容易编程，以后更容易阅读，但有时候性能是关键的，并且模板化的多态（如果你真的可以称之为多态）可以内联真的有帮助。