我需要就泛化与多态作出一个决定。
情景如下：我想让我的单olithic互相依赖的代码更加模块化，干净和可扩展。 目前这个阶段改变设计原则是可行的，而且在我看来也非常值得。
我是否应该引入纯虚基类（接口）或者模板呢？
我了解模板选项的基础知识：少一些间接性，性能更好，编译速度更快； 但是没有后期绑定等等。
STL并没有太多（或者根本没有）使用继承，Boost也是如此。但是我认为它们旨在成为程序员每两行代码就使用一次的非常基本的工具。
我认为继承和晚期绑定的方法更适用于插件式的大型代码片段和功能，这些功能应该在部署之后甚至在运行时进行交换、更新等。
我的情景有点介于两者之间。
我不需要在运行时动态交换代码，编译时可以。通常它也是一个非常核心和频繁使用的功能，在逻辑上不能分成大块。
这让我倾向于使用模板解决方案。对我来说，它看起来也更加清晰。
是否存在任何重大的不良影响？接口是否仍然是最佳选择？它们什么时候不是？哪一个更符合标准的C++风格？
我知道这有点主观，但我真的很想听听经验。我没有Scott Meyers的effective C++，所以我寄希望于你们：）
你说的基本正确，动态多态性（继承、虚函数）通常是当类型需要在运行时改变时的最佳选择（例如在插件架构中）。静态多态性（模板）是如果类型只应在编译时更改，则更好的选择。
模板的唯一潜在缺点是它们通常必须在头文件中定义（这意味着要包含更多代码），这经常导致编译时间较慢。
但从设计上来看，我不能看出在可能使用模板时存在任何问题。
哪种更符合标准 C++ 风格？
这取决于“标准C++风格”是什么。C ++标准库使用了各种方法。STL 对一切都使用模板，稍早的 IOStreams 库使用继承和虚函数，并且从 C 继承的库函数两者都不使用，当然。
如今，模板是迄今为止最受欢迎的选择，并且我必须说这是最“标准”的方法。
经典面向对象多态的特点：
dynamic_cast（并且它可能会导致客户端的问题），这可能很容易抵消其优点通过模板的编译时多态的特点：
请注意，无需决定使用哪种方式。您可以自由地混合使用它们两个（以及许多其他惯用语和范例）。通常，这会导致非常出色（而且表达力强）的代码。 （例如，请参见类型擦除之类的内容。）如果想了解通过巧妙混合范例可以实现什么，您可能想要浏览 Alexandrescu 的“现代 C++设计”。
这是一种虚假的对立。是的，继承和虚函数的主要用途在于 iostreams，它们非常古老，并且以与 std 库的其余部分相当不同的风格编写。
但是，许多“最酷”的现代 C++ 库（例如 boost）确实利用了运行时多态性，只是使用模板使其更方便使用。
boost::any 和 std::tr1::function（以前也来自 boost）是很好的例子。
它们都是单个项目的容器，其中具体类型在编译时未知（这在 any 中特别明显，因为它有自己的动态转换操作符以获取值）。
话虽如此，我在基本实用程序和库上使用它非常成功。但对于编写高级功能或硬件相关的东西，似乎不太适合我。 这意味着我将我的构建块模板化，但以传统方式构建房屋。
我在我的大型代码库中同时使用两者。当类型在编译时已知时，我使用模板进行设计；当其只在运行时已知时，则使用虚函数。我发现虚函数更易于编写和阅读，但是在性能关键时刻，如果使用模板多态（如果您真的可以称之为多态），那么可以内联它的事实确实有所帮助。
就我个人而言，最好的技术取决于你擅长什么。如果您对面向对象编程（OO）有更多经验，请使用OO。如果您对泛型有更多经验，请使用泛型。
两种技术都有一些相当的模式，这意味着对于很多事情，您可以使用任何一种。例如， OO中的策略与泛型中的策略或OO中的模板方法与泛型中的常见重复模式。
如果您计划重构已经正常运行但结构有点混乱的生产代码，请不要将其作为玩弄某些新设计技术的借口，因为一两年后，一旦您更好地理解了该技术，您可能会后悔如何重构您的代码。在学习技术时，很容易引入新的不灵活性。目标是改善现有代码的设计。如果您不熟练掌握一项技术，那么您怎么知道您正在改善设计，而不是在代码中建立大型象征性符号。
就我个人而言，我更擅长OO，并倾向于使用它，因为我知道我可以制定清晰易懂且大多数人可以更改的干净设计。我编写的大多数通用代码都旨在与其他通用代码进行接口交互，例如编写迭代器或用于算法的通用函数。