C++抽象类是什么 纯虚函数定义规范

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++习惯用法）： 是一种特殊的抽象类，通常只包含纯虚函数和虚析构函数，不含数据成员和普通函数实现，旨在定义行为契约。

纯虚函数在实际项目开发中有哪些典型应用场景？

纯虚函数在构建灵活、可扩展的系统时简直是利器。我个人觉得，它最亮眼的地方就在于“契约”和“多态”的结合。

1. 定义API或组件接口： 这是最常见的用途。比如你要开发一个插件系统，插件需要提供某些标准功能（如初始化、运行、关闭）。你可以定义一个抽象基类

   Plugin

   ，里面包含

   virtual bool init() = 0;

   、

   virtual void run() = 0;

   等纯虚函数。这样，任何第三方开发的插件，只要继承自

   Plugin

   并实现了这些纯虚函数，就能无缝集成到你的系统中。这确保了所有插件都遵循同一个“协议”。

2. 实现策略模式（Strategy Pattern）： 设想一个排序算法，你可能需要冒泡排序、快速排序、归并排序等多种方式。你可以定义一个抽象的

   sortStrategy

   类，里面有一个

   virtual void sort(int arr[], int size) = 0;

   纯虚函数。然后为每种具体算法创建一个派生类（

   BubbleSortStrategy

   、

   QuickSortStrategy

   ），实现各自的

   sort

   方法。客户端代码只需要持有

   SortStrategy

   的指针，就能根据需要动态切换排序算法，而无需修改核心逻辑。这让算法的选择变得非常灵活。

3. 模板方法模式（Template Method Pattern）： 这个模式也经常用到纯虚函数。一个算法的骨架在基类中定义，而某些步骤的实现则延迟到派生类。基类中的模板方法调用这些“可变”的步骤，而这些可变步骤就是纯虚函数。比如一个

   Game

   基类，有

   play()

   方法，里面调用了

   initGame()

   、

   startGame()

   、

   endGame()

   。如果

   initGame()

   和

   endGame()

   是通用的，但

   startGame()

   根据不同游戏类型有很大差异，那

   startGame()

   就可以是纯虚函数。

4. 强制继承体系中的特定行为： 有时候，你希望某个基类的所有派生类都必须实现某个特定的功能。纯虚函数就是强制这种行为的最佳方式。如果你不希望派生类忘记实现某个关键功能，就把它设为纯虚函数。

这些场景的核心思想都是：定义一套行为规范，让不同的实现去填充这些规范。它让代码结构更清晰，耦合度更低，也更容易扩展。

Noya

让线框图变成高保真设计。

44

查看详情

定义纯虚函数时常见的误区和最佳实践有哪些？

定义纯虚函数看起来简单，但有些地方确实容易踩坑，或者说，有更好的做法。

常见的误区：

1. 忘记在派生类中实现： 这是最常见的。如果你在派生类中继承了一个抽象类，但忘记实现所有的纯虚函数，那么这个派生类本身也会变成抽象类。如果你试图实例化它，编译器就会报错。初学者可能对此感到困惑，以为自己已经“实现了”所有功能，但其实漏掉了基类的纯虚函数。

2. 在构造函数或析构函数中调用纯虚函数： 这是一个比较隐蔽但非常危险的错误。在基类的构造函数执行时，派生类的部分还没有被构造，此时如果调用纯虚函数（即使派生类已经实现了），行为是未定义的，很可能导致程序崩溃。析构函数也类似，当基类析构时，派生类部分可能已经销毁，再调用其虚函数实现会导致问题。记住，在基类的构造/析构期间，虚函数机制的行为是特殊的，它会调用基类自己的版本（如果有），而不是派生类的版本。对于纯虚函数，这意味着没有版本可调用，或者行为异常。

3. 误以为

   = 0

   是赋初值： 就像前面说的，

   = 0

   不是给函数赋了个零值，它仅仅是一个语法标记，表示这个函数是纯虚函数，没有实现。

最佳实践：

1. 始终声明虚析构函数： 如果你的抽象类是作为基类使用的，并且可能会通过基类指针删除派生类对象，那么基类必须有一个虚析构函数。哪怕它是纯虚的（

   virtual ~Base() = 0;

   ），也需要提供一个空实现（在

   .cpp

   文件中

   Base::~Base() {}

   ），否则在删除派生类对象时，可能只会调用基类的析构函数，导致派生类资源泄漏。这是个很重要的点，很多时候被忽略。

2. 使用

   override

   关键字： 在派生类中实现纯虚函数时，总是加上

   override

   关键字。这能让编译器检查你是否真的覆盖了基类的虚函数，避免拼写错误或参数不匹配导致的潜在问题。这能大大提高代码的健壮性。

3. 保持接口的最小化和内聚性： 抽象类定义的接口应该尽可能小且职责单一。不要把不相关的功能都塞到一个接口里。一个好的接口应该只包含客户端需要知道和调用的方法。

4. 提供文档或注释： 清楚地说明每个纯虚函数的预期行为和派生类需要实现的职责。这对于使用你的抽象类的开发者来说非常重要。

这些经验之谈，都是在实际开发中慢慢积累出来的。遵循这些，能让你的C++面向对象设计更加稳健和易于维护。