c++ - 抽象类与模板——好的实践

Question

假设我有某种类型的类，它表示算法并且该算法需要数据中的某些特殊内容(例如，某些成员函数)。

例如我们可以这样做:

                                          <<interface>>
+------------------------+               +------------+
|       Algorithm        |    <<uses>>   |    Data    |
+------------------------+-------------->+------------+
| + doJob(inData : Data) |               | +getPixel()|
+------------------------+               +------------+

并且我们可以强制 Algorithm 的用户每次想使用类算法时都从 Data 继承。我们也可以做一个模板:

template<typename T>
doJob(T&& inputData){
   //implementation
}

(没有类的函数以简化事情)

并且我们强制我们的客户创建类，这些类具有专有名称的方法，但我们不让他实现我们的抽象类(不同语言的接口(interface))(也许性能更好一点？)

我的问题是:

哪种方法更好？

• 当有选择时，我们应该在库中以模板方式还是抽象方式实现事物？

• 标准是否有理由不定义一些标准“接口(interface)”，例如 std::container 或 std::factory(只是示例)？

Answer 1

其实你的问题不止一个，下面我们一一解答:

Which approach is better?

总的来说，两者都不是更好。每个人都有长处和短处。但您确实得出了一个有趣的观点:在更抽象的层面上，这两者几乎相同。

When having the choice should we implement things in a template way or abstract way in a library?

使用模板您可以获得:

1. 一般而言，执行速度更快。它可以更快很多，因为可以进行大量内联，然后进行优化。 OTOH，具有先进的去虚拟化编译器/链接器和不能太多内联/优化的函数，您可能会获得几乎相同的速度。

2. 较慢的编译时间。它可能会慢很多，尤其是如果您采用“花哨的模板元编程”方式。

3. 更糟糕的编译器错误。它们可能会更糟，尤其是如果您采用“花哨的模板元编程”方式。当 C++ 获得对概念的支持时，应该可以避免这种情况。

4. 如果您仔细设计，类型安全性会得到改善。 OTOH，如果你不小心，你最终会遇到比 Smalltalk 更糟糕的鸭子打字。概念也是一种可以在这方面提供帮助的工具。

使用虚函数/接口(interface)，您将获得:

1. 解耦设计，如果您小心的话，一个文件的更改不需要重新编译其他文件，并且编译时间可以更快。
2. 运行时多态性，这意味着您可以动态加载代码(这并不像听起来那么容易，但是，这是可能的)
3. 具有 OO 经验的人看起来更熟悉的东西。

Is there a reason for standard not to define some standard "Interfaces" like std::container or std::factory (just examples)?

我想人们可以找到很多“低级”原因，但根本原因是性能。也就是说，STL 被设计为“尽可能快”，现在几乎不可能将一些(有用的)接口(interface)“放在最上面”。