C++接口技术疑问：接口与抽象类区别及应用优势探讨

嘿，我来帮你把这些关于C++接口和抽象类的疑问理清楚～

一、你对抽象类和接口的理解基本正确！ #

你说的“抽象类至少包含一个纯虚方法，同时可以有普通方法；接口仅包含纯虚方法”这个核心区别完全没问题。不过要补充一个C的细节：C语言本身并没有官方的“接口”概念，我们平时说的“接口”，其实是用仅包含纯虚方法（和虚析构函数）的抽象类来模拟实现的。

比如你给出的示例：
抽象类（带部分默认实现）：

class MyAbstractClass {
public:
    virtual ~MyAbstractClass() {}
    virtual void Method1();
    virtual void Method2();
    virtual void Method3() = 0;
};

这里Method1和Method2有默认实现（哪怕是空的），派生类可以选择重写或者直接复用这些逻辑；而Method3是纯虚方法，必须由派生类自己实现，所以这个类是抽象类，不能直接实例化。

接口类（全纯虚方法）：

class MyInterface {
public:
    virtual ~MyInterface() {}
    virtual void Method1() = 0;
    virtual void Method2() = 0;
};

所有方法都是纯虚，没有任何默认实现，派生类必须把这些方法全部实现才能被实例化。另外接口的方法一般都是public的，因为它的核心作用就是对外暴露一个“行为契约”。

二、为什么要使用接口？普通类能替代吗？ #

接口的核心价值在于解耦模块和定义行为契约，这是普通类很难替代的：

1. 接口是一种“行为契约” #

它只规定了“必须做什么”，完全不关心“怎么做”。比如你教授提到的网络类和分析器类的场景：
假设我们有WiFiNetwork、EthernetNetwork两种不同的网络实现类，如果分析器直接依赖这两个具体类，那以后新增5GNetwork时，分析器的代码必须修改才能支持新类型。但如果我们定义一个NetworkInterface，里面声明getNetworkStats()这样的纯虚方法，所有网络类都实现这个接口，分析器只需要依赖NetworkInterface——不管底层是哪种网络，只要它遵守了接口的契约，分析器就能调用getNetworkStats()获取数据，完全不需要关心具体的实现细节。

2. 普通类替代接口会带来耦合问题 #

如果用普通类做基类，基类往往会包含成员变量或者默认实现，派生类会不自觉地依赖这些细节，导致模块间耦合度极高。比如基类的一个默认实现修改了，所有派生类都可能受到影响；而接口没有任何实现和数据，派生类只需要遵守契约，完全自主实现逻辑，耦合度极低。

另外，普通类作为基类时，多继承容易出现菱形继承、数据冗余等问题，但接口因为没有数据成员，多继承非常安全——一个类可以同时实现多个接口，比如class MyDevice : public NetworkInterface, public StorageInterface，这样就能给类赋予多种行为契约，而不会有继承冲突。

三、接口在类间通信中的核心优势 #

总结下来，接口在类间通信时的优势主要有三点：

• 解耦模块依赖：高层模块（比如分析器）只依赖抽象的接口，不依赖底层具体类，底层类的修改不会影响高层模块，这完全符合软件工程里的依赖倒置原则。
• 提高代码扩展性：新增一个符合接口的类（比如新的网络类型），不需要修改现有代码，直接就能被使用接口的模块兼容。
• 统一行为标准：所有实现接口的类都遵循同一个行为规范，调用方不需要记住不同类的不同方法名，只需要调用接口定义的方法即可，代码更简洁易维护。

内容的提问来源于stack exchange，提问作者user7152472