C++中抽象类不能实例化，必须由派生类实现其纯虚函数，用于定义接口契约；普通类可直接实例化，所有函数均有实现；接口类是仅含纯虚函数的抽象类，用于规范行为。
C++中的抽象类是一种不能直接创建对象的类，它至少包含一个纯虚函数。纯虚函数是一种特殊的虚函数，其声明以
= 0结尾，表示该函数在基类中没有实现，必须由派生类提供具体实现。这种机制强制派生类遵循特定的接口契约。
抽象类在C++面向对象设计里扮演着一个“蓝图”或“契约”的角色。它的主要目的是定义一个通用接口，而将具体的实现细节留给它的派生类。想象一下，我们想设计一套图形绘制系统，里面有各种形状：圆形、矩形、三角形。它们都需要一个
draw()方法。但
Shape本身怎么画呢？它没法画，因为它太抽象了。这时候，我们就可以把
draw()定义成一个纯虚函数。
class Shape {
public:
virtual void draw() = 0; // 纯虚函数
virtual ~Shape() {} // 虚析构函数很重要
};你看，
= 0不是说它等于零，而是一个特殊的语法，告诉编译器：“这个函数我（基类）不实现，你（派生类）必须实现。”如果一个类包含了哪怕一个纯虚函数，那么这个类就自动变成了抽象类，你不能直接
Shape myShape;这样去创建它的对象。这很合理，一个抽象的“形状”是无法被具体绘制的。
派生类，比如
Circle或
Rectangle，就必须提供
draw()的具体实现。如果
Circle没有实现
draw()，那
Circle本身也会变成抽象类，它下面的子类又得继续实现。这种机制确保了所有从
Shape继承下来的具体形状，都一定能被
draw()。它提供了一种强大的多态性基础，我们可以通过基类指针或引用来操作不同类型的派生类对象，统一调用
draw()，而不用关心具体是哪个形状。这种感觉就像是，我只知道它是个“形状”，我只管叫它“画”，至于怎么画，那是它自己的事。
立即学习“C++免费学习笔记（深入）”；
C++中抽象类与普通类、接口类的核心区别是什么？
普通类，或者说具体类（concrete class），是可以直接实例化对象的。它所有的成员函数都有具体的实现，或者有默认实现。你可以直接
MyClass obj;来用它。
抽象类则不同，它不能直接实例化。它的存在更多是为了作为其他类的基类，提供一个统一的接口或者部分实现。它至少含有一个纯虚函数，强迫派生类去实现这个函数。这就像是公司里定了个规矩：所有部门经理必须每个月提交一份报告，但报告的具体内容和格式，每个部门自己定。抽象类就是这个“规矩”的制定者。
至于“接口类”，在C++里，这通常指的是一个只有纯虚函数和（可能有的）虚析构函数的抽象类。它不包含任何数据成员，也不包含任何非纯虚函数的实现。它的目的就是纯粹地定义一个接口，一个行为规范。比如一个
Clickable接口，里面只有一个
onClick()纯虚函数。任何实现了这个接口的类，都意味着它“可以被点击”。C++本身没有Java或C#那样显式的
interface关键字，但通过这种纯虚函数+虚析构函数的抽象类，就能实现接口的概念。它们的区别在于：
- 普通类： 可实例化，所有函数都有实现。
- 抽象类： 不可实例化，至少一个纯虚函数，可包含数据成员和非纯虚函数实现。
- 接口类（C++习惯用法）： 是一种特殊的抽象类，通常只包含纯虚函数和虚析构函数，不含数据成员和普通函数实现，旨在定义行为契约。
纯虚函数在实际项目开发中有哪些典型应用场景？
纯虚函数在构建灵活、可扩展的系统时简直是利器。我个人觉得，它最亮眼的地方就在于“契约”和“多态”的结合。
定义API或组件接口： 这是最常见的用途。比如你要开发一个插件系统，插件需要提供某些标准功能（如初始化、运行、关闭）。你可以定义一个抽象基类
Plugin
，里面包含virtual bool init() = 0;
、virtual void run() = 0;
等纯虚函数。这样，任何第三方开发的插件，只要继承自Plugin
并实现了这些纯虚函数，就能无缝集成到你的系统中。这确保了所有插件都遵循同一个“协议”。实现策略模式（Strategy Pattern）： 设想一个排序算法，你可能需要冒泡排序、快速排序、归并排序等多种方式。你可以定义一个抽象的
SortStrategy
类，里面有一个virtual void sort(int arr[], int size) = 0;
纯虚函数。然后为每种具体算法创建一个派生类（BubbleSortStrategy
、QuickSortStrategy
），实现各自的sort
方法。客户端代码只需要持有SortStrategy
的指针，就能根据需要动态切换排序算法，而无需修改核心逻辑。这让算法的选择变得非常灵活。模板方法模式（Template Method Pattern）： 这个模式也经常用到纯虚函数。一个算法的骨架在基类中定义，而某些步骤的实现则延迟到派生类。基类中的模板方法调用这些“可变”的步骤，而这些可变步骤就是纯虚函数。比如一个
Game
基类，有play()
方法，里面调用了initGame()
、startGame()
、endGame()
。如果initGame()
和endGame()
是通用的，但startGame()
根据不同游戏类型有很大差异，那startGame()
就可以是纯虚函数。强制继承体系中的特定行为： 有时候，你希望某个基类的所有派生类都必须实现某个特定的功能。纯虚函数就是强制这种行为的最佳方式。如果你不希望派生类忘记实现某个关键功能，就把它设为纯虚函数。
这些场景的核心思想都是：定义一套行为规范，让不同的实现去填充这些规范。它让代码结构更清晰，耦合度更低，也更容易扩展。
定义纯虚函数时常见的误区和最佳实践有哪些？
定义纯虚函数看起来简单，但有些地方确实容易踩坑，或者说，有更好的做法。
常见的误区：
忘记在派生类中实现： 这是最常见的。如果你在派生类中继承了一个抽象类，但忘记实现所有的纯虚函数，那么这个派生类本身也会变成抽象类。如果你试图实例化它，编译器就会报错。初学者可能对此感到困惑，以为自己已经“实现了”所有功能，但其实漏掉了基类的纯虚函数。
在构造函数或析构函数中调用纯虚函数： 这是一个比较隐蔽但非常危险的错误。在基类的构造函数执行时，派生类的部分还没有被构造，此时如果调用纯虚函数（即使派生类已经实现了），行为是未定义的，很可能导致程序崩溃。析构函数也类似，当基类析构时，派生类部分可能已经销毁，再调用其虚函数实现会导致问题。记住，在基类的构造/析构期间，虚函数机制的行为是特殊的，它会调用基类自己的版本（如果有），而不是派生类的版本。对于纯虚函数，这意味着没有版本可调用，或者行为异常。
误以为
= 0
是赋初值： 就像前面说的，= 0
不是给函数赋了个零值，它仅仅是一个语法标记，表示这个函数是纯虚函数，没有实现。
最佳实践：
始终声明虚析构函数： 如果你的抽象类是作为基类使用的，并且可能会通过基类指针删除派生类对象，那么基类必须有一个虚析构函数。哪怕它是纯虚的（
virtual ~Base() = 0;
），也需要提供一个空实现（在.cpp
文件中Base::~Base() {}），否则在删除派生类对象时，可能只会调用基类的析构函数，导致派生类资源泄漏。这是个很重要的点，很多时候被忽略。使用
override
关键字： 在派生类中实现纯虚函数时，总是加上override
关键字。这能让编译器检查你是否真的覆盖了基类的虚函数，避免拼写错误或参数不匹配导致的潜在问题。这能大大提高代码的健壮性。保持接口的最小化和内聚性： 抽象类定义的接口应该尽可能小且职责单一。不要把不相关的功能都塞到一个接口里。一个好的接口应该只包含客户端需要知道和调用的方法。
提供文档或注释： 清楚地说明每个纯虚函数的预期行为和派生类需要实现的职责。这对于使用你的抽象类的开发者来说非常重要。
这些经验之谈，都是在实际开发中慢慢积累出来的。遵循这些，能让你的C++面向对象设计更加稳健和易于维护。
