C++中没有“接口”本身的概念。AFAIK，接口首先在Java中引入，以解决缺少多重继承的问题。事实证明，这个概念非常有用，在C++中使用抽象基类也可以达到同样的效果。

抽象基类是一个类，其中至少一个成员函数（Java语言中的方法）是使用以下语法声明的纯虚拟函数：

class A
{
  virtual void foo() = 0;
};

抽象基类不能实例化，即不能声明类A的对象。只能从A派生类，但任何不提供foo（）实现的派生类也将是抽象的。为了停止抽象，派生类必须为其继承的所有纯虚拟函数提供实现。

请注意，抽象基类可以不仅仅是一个接口，因为它可以包含非纯虚拟的数据成员和成员函数。接口的等价物是一个抽象基类，没有任何数据成员，只包含纯虚拟函数。

而且，正如MarkRansom所指出的，抽象基类应该像任何基类一样提供虚拟析构函数。

考虑这一点的一个好方法是继承接口而不是继承实现。在C++中，您可以同时继承接口和实现（公共继承），也可以只继承实现（私有继承）。在Java中，您可以选择只继承接口，而不继承实现。

如果您使用的是Microsoft的C++编译器，则可以执行以下操作：

struct __declspec(novtable) IFoo
{
    virtual void Bar() = 0;
};

class Child : public IFoo
{
public:
    virtual void Bar() override { /* Do Something */ }
}

我喜欢这种方法，因为它会产生更小的接口代码，生成的代码大小也会明显更小。novtable的使用删除了该类中对vtable指针的所有引用，因此您永远不能直接实例化它。请参阅此处的文档-novtable。

以上都是好答案。还有一件事你应该记住——你也可以有一个纯粹的虚拟析构函数。唯一的区别是你仍然需要实现它。

困惑的

    --- header file ----
    class foo {
    public:
      foo() {;}
      virtual ~foo() = 0;

      virtual bool overrideMe() {return false;}
    };

    ---- source ----
    foo::~foo()
    {
    }

你想这样做的主要原因是，如果你想提供接口方法，就像我所说的那样，但让重写它们成为可选的。

要使类成为接口类，需要一个纯虚方法，但所有的虚方法都有默认实现，因此唯一剩下的方法就是析构函数。

在派生类中重新实现析构函数根本没什么大不了的——我总是在派生类里重新实现一个析构函数，不管是虚拟的还是非虚拟的。

在C++11中，您可以轻松避免完全继承：

struct Interface {
  explicit Interface(SomeType& other)
  : foo([=](){ return other.my_foo(); }), 
    bar([=](){ return other.my_bar(); }), /*...*/ {}
  explicit Interface(SomeOtherType& other)
  : foo([=](){ return other.some_foo(); }), 
    bar([=](){ return other.some_bar(); }), /*...*/ {}
  // you can add more types here...

  // or use a generic constructor:
  template<class T>
  explicit Interface(T& other)
  : foo([=](){ return other.foo(); }), 
    bar([=](){ return other.bar(); }), /*...*/ {}

  const std::function<void(std::string)> foo;
  const std::function<void(std::string)> bar;
  // ...
};

在这种情况下，接口具有引用语义，即您必须确保对象比接口更长寿（也可以创建具有值语义的接口）。

这些类型的接口有其优点和缺点：

它们比基于继承的多态性需要更多的内存。它们通常比基于继承的多态性更快。在那些你知道最终类型的情况下，它们要快得多！（像gcc和clang这样的一些编译器在没有/继承自具有虚拟函数的类型的类型中执行更多的优化）。

最后，继承是复杂软件设计中所有邪恶的根源。在Sean Parent的《基于价值语义和概念的多态性》（强烈推荐，此处解释了该技术的更好版本）中，研究了以下案例：

假设我有一个应用程序，在其中我使用MyShape界面处理我的形状：

struct MyShape { virtual void my_draw() = 0; };
struct Circle : MyShape { void my_draw() { /* ... */ } };
// more shapes: e.g. triangle

在应用程序中，您可以使用YourShape界面对不同的形状执行相同的操作：

struct YourShape { virtual void your_draw() = 0; };
struct Square : YourShape { void your_draw() { /* ... */ } };
/// some more shapes here...

现在，假设您想使用我在您的应用程序中开发的一些形状。从概念上讲，我们的形状具有相同的界面，但要使我的形状在您的应用程序中工作，您需要按如下方式扩展我的形状：

struct Circle : MyShape, YourShape { 
  void my_draw() { /*stays the same*/ };
  void your_draw() { my_draw(); }
};

首先，修改我的形状可能根本不可能。此外，多重继承导致了意大利面代码的发展（假设第三个项目使用TheirShape接口……如果他们也调用绘图函数my_draw会发生什么？）。

更新：有一些关于非继承多态性的新参考：

Sean Parent的继承权是恶语的基础。Sean Parent的价值语义和基于概念的多态性谈话。Pyry Jahkola的无继承多态性演讲和poly库文档。Zach Laine的实用类型擦除：用优雅的设计模式解决OOP问题。Andrzej的C++博客-类型Erasure第i、ii、iii和iv部分。ConceptC中混合对象和概念的运行时多态泛型编程++Boost.TypeErasure文档Adobe Poly文档Boost.Any，std:：任何提案（修订版3），Boost.Spirit:：hold_Any。

除了上面写的内容，还有一点补充：

首先，确保析构函数也是纯虚拟的

第二，您可能希望在执行时实际上继承（而不是正常继承），只是为了获得好的度量。

在C++20中，可以使用概念而不是类。它比继承更有效率。

template <class T>
concept MyInterface = requires (T t) {
    { t.interfaceMethod() };
};

class Implementation {
public:
    void interfaceMethod();
};
static_assert(MyInterface<Implementation>);

然后您可以在函数中使用它：

void myFunction(MyInterface auto& arg);

限制是不能在容器中使用它。