在C的语境里继承可能是被误解最多的一个词。不是说它的语法有多复杂——class B : public A一行而已而是这行代码背后那套类型之间如何关联的思想真正坑过无数人。我在团队里带新人的时候发现大部分人把继承当成偷懒复用代码的工具父类写一个函数子类直接拿来用爽是爽了等到后面要改需求一个父类改了一群子类一起炸根本不知道该从哪里下手。所以我想把继承这件事从头到尾讲清楚它到底解决什么问题、C提供了哪几种继承方式、为什么会有对象切片、虚函数和析构函数的那些约定是怎么回事以及最关键的——什么时候你根本不该用继承。如果你是刚开始接触C面向对象或者写了一阵子还是对封装继承多态只知其名不知其实这篇文章应该能帮你在画类和类的关系时少踩点坑。1. 为什么需要继承数据复制的痛与类型建模的刚需1.1 没有继承时你会在复制粘贴里崩溃先说一个最直观的理由代码复用。假设你要写一个动物园系统里面有狗、猫、鸟。没有继承的时候每个类都得独立实现一遍名字、年龄、吃饭、睡觉这些通用行为代码长什么样呢class Dog { public: void eat() { std::cout name_ is eating\n; } void sleep() { std::cout name_ is sleeping\n; } private: std::string name_; int age_; }; class Cat { public: void eat() { std::cout name_ is eating\n; } void sleep() { std::cout name_ is sleeping\n; } private: std::string name_; int age_; };两个类几乎一模一样唯一的区别是类名。你当然可以把这些重复代码复制粘贴但复制粘贴一时爽维护起来就是火葬场今天要加一个年龄校验你得在Dog和Cat里各改一遍明天系统里加一只鹦鹉和一只企鹅你又得复制两份。改漏一个类Bug就藏在你看不到的地方。这时候你自然而然就会想能不能把这些公共属性和方法抽出来单独放在一个类里让其他类继承它这就是继承最朴素的动机把共性上移把差异留在子类。1.2 继承背后的is-a关系才是面向对象建模的核心如果继承只是代码复用的工具那它和把公共代码塞进工具类里调用没有本质区别。但继承真正的价值在于它表达了类型之间的一种逻辑关系is-a是一种。狗是一种动物猫也是一种动物动物园里的老虎、企鹅也都是一种动物。这种关系不能用组合has-a拥有一个来表达因为狗不是拥有一个动物属性狗本身就是一个动物。用生活化的类比来说继承对应的是人类认知里的分类学。你看到一只金毛首先会把它归到狗然后归到动物。这个分类层级本身就是一种知识组织方式所有动物都要呼吸、移动、摄取能量所以动物这个父类应该容纳这些共性狗有特殊的吠叫行为鸟有特殊的飞行能力所以这些差异放到各自的子类里。C用语法把这个认知模型落地让你能直接告诉编译器Dog是一种Animal所以凡是可以使用Animal的地方都可以塞一个Dog进去。这个忠实于认知模型的设计很有价值因为它让代码结构能跟随问题域演进。当产品经理说动物园里所有动物都需要打疫苗你只需要在Animal里加一个vaccinate()所有子类自动获得这个能力当他说只有哺乳动物需要哺乳你再在Animal和Dog之间加一层Mammal整个类型层级依然稳如磐石。这就是面向对象里开闭原则对扩展开放对修改关闭的最典型应用新需求来了优先考虑扩展子类而不是到处修改已有的类。1.3 封装、继承、多态本来就是一体的很多教材把封装继承多态并列成三个孤立的特性这其实是个很大的误导。这三个东西是互相配合的封装负责把数据和操作藏进类的边界内继承负责建立起类型之间的层级关系和代码复用通道而多态则通过基类指针或引用操作一组彼此相关的派生类对象。没有继承多态就失去了施展的舞台——因为你没有一个统一的基类类型去指向不同的子类没有多态继承就退化成单纯的代码复制你写了一堆类却还是得一个个判断具体类型去调用方法。所以学继承的时候脑子里要带着另外两个特性一起转。你在设计一个继承体系时其实是在为未来的多态调用铺路。Dog是一个Animal这句话一旦写成代码后面就会出现Animal* p new Dog()这种用法而多态机制会保证调用的是狗的那份吃饭行为而不是动物共性的那份。这个东西在后面第5节详细讲但你要先建立这个整体感。2. 继承的基碐语法与访问控制先把可见性规则刻进肌肉记忆2.1 一个最基础的继承例子C的继承语法很好写麻烦的是背后那套访问级别规则。先看基础形态class Animal { public: Animal(const std::string name, int age) : name_(name), age_(age) {} void eat() { std::cout name_ is eating\n; } protected: std::string name_; // 保护成员派生类可见外部不可见 private: int age_; // 私有成员只有Animal自己和友元能访问 }; class Dog : public Animal { public: Dog(const std::string name, int age) : Animal(name, age) {} void bark() { std::cout name_ is barking\n; // 可以访问name_ // std::cout age_; // 编译错误age_是Animal私有 } };这里最需要注意的细节是age_虽然是私有成员但它依然存在于每个Dog对象的内存布局里只是Dog的代码碰不到它。很多初学者以为派生类访问不了私有成员那私有成员就不属于派生类这是错的。继承是把整个父类子对象嵌入到子类对象里访问权是一回事存在性是另一回事。2.2 public、protected、private成员在继承体系里的可见性访问控制是C里最容易云里雾里的部分我来做个表把它压缩成一套规则。成员声明位置外部代码Derived类内部Derived的派生类内部public可见可见可见protected不可见可见可见private不可见不可见不可见可以这样记protected是给家族内部使用不对外暴露的中间地带。你说外部代码不要直接改Dog的名字但Dog和它的子类可以读就把name_声明成protected。这是封装和继承的折中方案。还有个高频坑构造函数、析构函数、赋值运算符重载、友元关系都不会被继承。派生类不会自动拥有基类的友元想用基类的友元函数访问派生类私有成员得重新声明构造函数不会被继承子类必须在初始化列表里调用基类的构造函数。这些点看起来很冷门面试和实际代码审查里它们都是常客。2.3 using声明访问级别的白名单调整继承之后如果你发现基类的某个public成员在子类里的访问级别不合适可以用using声明把它调回来。最常见的场景是private继承下一节细说之后想把基类的某个接口重新暴露给外部class Base { public: void func1(); void func2(); }; class Derived : private Base { public: using Base::func1; // 只把func1重新设为publicfunc2保持私有 };这个技巧在用private继承表达组合关系但需要局部暴露接口的时候非常好用。它相当于你接管了基类的访问级别控制明确告诉读者这个类型确实拥有基类的实现但值得对外暴露的只有func1。这种按需放行的思路比一股脑把整个基类接口全暴露出去要严谨得多。3. public、protected、private三种继承方式选错就是设计事故3.1 一张表看懂三种继承方式对成员访问级别的影响热搜词里不同的继承方式是C初学者普遍关心的问题。很多人写class B : public A但对protected继承和private继承完全没有概念。其实规则很简单继承方式会压低基类成员在派生类中的访问级别。基类中被声明的级别public继承后protected继承后private继承后publicpublicprotectedprivateprotectedprotectedprotectedprivateprivate不可见不可见不可见注意看规律public继承不改写访问级别protected继承把基类所有public压成protectedprivate继承把基类所有public和protected都压成private。基类的private成员在三种继承方式下都不可见——这一点自始至终不变。3.2 三种继承方式分别表达什么设计意图public继承表达的是is-a。Dog继承Animal外部可以把Dog当作Animal来用基类接口完整保留。这是99%的情况下你该用的那种继承。private继承表达的是has-a实现继承。它把基类当作一块内部实现材料完全不暴露给外部。外面调用q.func()会直接编译报错。它本质上是一种组合的变体你内部拥有基类的所有能力但对外不承诺任何基类接口。什么时候用呢当你想复用Base的实现但不想让这个复用关系被外界感知的情况下。比如一个Timer类内部需要用到Log类的方法但用户不该看到Timer是一个Log此时private继承或者成员对象组合都是合理的。C标准库里有个经典例子std::stack适配器内部基于deque实现如果要用继承那只能是private继承绝不可能是public。protected继承是一种很少见的中间态。它对外部隐藏基类接口但对派生类的子类仍然可见基类接口。也就是说只有这个继承家族内部能使用基类的能力家族外部完全隔离。实际工程里protected继承相当罕见我写过这么多年C用到它的次数一只手数得过来更多时候你该思考是不是private继承或者组合更合适。3.3 选择继承方式时的一个判断框架我习惯这样判断先问自己这层关系能不能用is-a解释。能用public继承前提是满足Liskov替换原则后面第7节展开。不能但确实需要复用Base的实现优先考虑组合成员对象只有当你想访问Base的protected成员、或者需要重写虚函数时才用private继承。你不能确定就别用继承。C里组合能表达绝大多数关系继承多一层就多一份耦合。这个判断框架不是我的发明它来自常年踩坑后的共识。写代码的时候每次敲下:后面那个关键字之前先问自己一句这个冒号代表的关系我真的说清楚了吗4. 构造顺序、析构顺序与对象切片继承中的第一个大坑4.1 构造和析构的顺序到底怎么排继承体系下对象的构造不是一蹴而就的。看这段代码class Animal { public: Animal() { std::cout Animal构造\n; } ~Animal() { std::cout Animal析构\n; } }; class Dog : public Animal { public: Dog() { std::cout Dog构造\n; } ~Dog() { std::cout Dog析构\n; } }; int main() { Dog d; }输出顺序是Animal构造 Dog构造 Dog析构 Animal析构规则一句话先基类后派生类地构造再派生类后基类地析构。原因很朴素派生类里很可能要访问基类的成员变量所以基类部分必须先就绪析构时派生类可能还要用到基类资源所以自己的析构先执行彻底清理完再拆基类的地基。这个顺序是C标准保证的不会有例外。4.2 基类没有默认构造函数时的显式初始化如果基类只有带参构造函数派生类必须显式在初始化列表里调用它否则编译直接报错class Base { public: Base(int x) {} }; class Derived : public Base { public: Derived() : Base(42) {} // 必须显式调用 };这里想提醒一个隐蔽问题派生类构造函数里如果你忘了写Base(42)编译器不会聪明地替你猜一个值它会直接抱怨no matching function for call to Base()。很多初学者看到这个报错容易懵其实就是你没满足基类构造的前提条件。4.3 对象切片值传递方式下派生类信息会断尾这是继承体系中新手最容易踩的坑之一。当你用值传递、值赋值的方式把派生类对象塞给基类变量时派生类独有的那部分会被硬生生切掉Dog d(旺财, 3); Animal a d; // 切片a只保留了Animal部分bark、狗特有的字符串全丢了d对象里本来是Animal子对象Dog独有部分叠在一起的但Animal a这个变量只有Animal那么大的空间编译器只能把Animal子对象拷贝过去Dog特有的成员直接丢弃。这就是传说中的对象切片Object Slicing。切片带来的问题是你总觉得传进去的是一只狗但拿到的只是一只看着像狗但完全没有狗的行为的动物。更隐蔽的坑是在容器里std::vectorAnimal zoo; zoo.push_back(dog1); // 静默切片 zoo.push_back(cat1); // 静默切片于是zoo里的每个元素都变成了Animal脱模版后续就算想恢复成Dog也恢复不了信息已经丢了。解决办法是用指针或者引用std::vectorstd::unique_ptrAnimal zoo; zoo.push_back(std::make_uniqueDog(旺财, 3));用unique_ptrAnimal这个操作在C11之后属于标准姿势容器存的是指针指向的是完整的Dog对象不切片而且通过基类指针还能触发虚函数多态。提示如果你在代码里看到vector 这种写法基本可以断定这里是切片重灾区尤其是元素被当作Animal操作时子类扩展的行为会被全部隐形阉割。这一节的坑之所以关键是因为它不报错。切片是静默发生的你很难通过编译错误发现它只有运行时行为不对才能察觉到。所以记住一条准则多态对象永远用指针或引用传绝对不要用值传。5. 重写、隐藏与虚函数继承和多态的分界线5.1 虚函数决定调谁的实现名字隐藏只是遮住了先看代码class Animal { public: virtual void speak() { std::cout 动物叫\n; } void move() { std::cout 动物移动\n; } }; class Dog : public Animal { public: void speak() override { std::cout 汪汪\n; } // 重写虚函数 void move() { std::cout 狗在跑\n; } // 名字隐藏非虚函数 };用基类指针调用Animal* p new Dog(); p-speak(); // 虚函数调Dog::speak输出汪汪 p-move(); // 非虚调Animal::move输出动物移动注意move()这个函数Dog里确实写了同名函数但它不会通过基类指针触发因为基类的move()没有virtual。这时候调用哪个版本取决于指针的静态类型也就是声明类型Animal*而不是实际指向的对象类型。这种现象叫名字隐藏Name Hiding。很多新手会困惑为什么子类写了同名函数父类指针调起来还是父类版本原因就是virtual这个词。只有虚函数才会走动态绑定——运行时根据对象实际类型决定调用哪份实现非虚函数走静态绑定——编译时就看你的指针是啥类型。所以当你希望子类可以替换父类的行为时记住把函数声明为virtual并且加上override关键字C11之后这是标准习惯。5.2 虚函数表多态背后的机制一张图讲清虚函数的实现机制简单说就是每个含有虚函数的类会有一张虚函数表vtable里面存着这个类各个虚函数的真实地址。每个对象内部有一个隐藏的指针vptr指向这个表。调用虚函数时编译器不直接写死要调哪个函数而是从对象拿vptr从vptr拿表再从表里取真正的函数地址。所以Animal* p new Dog()后p这个指针虽然声明成Animal*但它指向的对象是Dog对象里的vptr指向的是Dog的虚函数表表里speak()那一栏存的是Dog::speak的地址。调用p-speak()就等于运行那个真实存储在Dog虚函数表中的地址——自然就输出了汪汪。这个机制带来的一个重要推论是多态需要指针或引用 虚函数两个条件同时满足。前面说的切片场景里Animal a d不仅切掉了Dog部分还让vptr也变成了Animal表的vptr多态彻底失效。5.3 基类析构函数必须virtual否则泄漏这是C面试高频题也是实际内存问题的元凶。看代码class Animal { public: ~Animal() {} // 非虚 }; class Dog : public Animal { public: ~Dog() { delete [] barkToy_; } // 释放子类资源 private: int* barkToy_; }; Animal* p new Dog(); delete p; // 危险当基类析构函数不是虚函数时delete p只会按静态类型Animal去调用析构Dog析构函数根本不会执行barkToy_就泄漏了。换句话说如果这个类要被当作基类使用析构函数必须是virtual。有一个很简单粗暴的口诀只要类里有虚函数就把析构函数也写成virtual。即便是空实现也得写class Animal { public: virtual ~Animal() default; };default加上virtual既保留了默认实现又保证派生类析构能正确串联。5.4 纯虚函数与抽象类接口继承的正确姿势当你想定义一个接口——只声明能力不提供实现——就用纯虚函数class Shape { public: virtual double area() const 0; virtual ~Shape() default; }; class Circle : public Shape { public: double area() const override { return 3.1415926 * r_ * r_; } private: double r_ 1.0; }; 0表示这个类是抽象类不能直接实例化必须等子类完整实现所有纯虚函数后才能创建对象。这其实就是面向对象接口的红线用法你定义的是一个契约子类必须履行。设计上抽象基类往往就是多态根它把接口和实现分离让调用方只依赖于Shape这个抽象而不依赖具体是Circle还是Rectangle。6. 菱形继承与虚继承多继承的复杂度管理6.1 C为什么会允许多继承和Java、C#不同C允许一个类继承多个基类。这个设计让C的表达力更强但也带来了菱形继承这类麻烦。多继承本身不是洪水猛兽比如一个FlyingCar同时继承Car和Aircraft逻辑上说得通。问题是当多个父类拥有同一个祖先时麻烦就来了。6.2 菱形继承的二义性和数据冗余菱形继承的结构长这样Animal / \ Dog Bird \ / DogBirdDogbird同时继承Dog和Bird而Dog和Bird又都继承自Animal。如果没有特殊处理DogBird对象里会出现两份Animal子对象。这带来两个问题第一二义性。dogbird.name_到底是Dog带来的那份Animal的name还是Bird带来的那份编译器无法判断直接报错。你得用作用域限定dogbird.Dog::name_ 阿黄; // 指定用Dog路径下的Animal子对象 dogbird.Bird::name_ 小飞; // 指定用Bird路径下的Animal子对象能访问但很繁琐而且你其实维护着两份互不相干的Animal状态。第二数据冗余和不一致。两份Animal子对象意味着同一个祖先数据被复制了两遍一份通过Dog改动一份通过Bird改动很容易出现逻辑上同一个人两种体重的怪事。6.3 虚继承让菱形顶端的类只保留一份解决方式是把共享的基类声明为虚基类class Animal { /* ... */ }; class Dog : virtual public Animal { /* ... */ }; class Bird : virtual public Animal { /* ... */ }; class DogBird : public Dog, public Bird { /* ... */ };加了virtual关键字后C会保证最终派生类里只有一份Animal子对象Dog和Bird共享这一份二义性和冗余一起消失。这就是虚继承Virtual Inheritance。但虚继承不是没有代价。它的对象布局更复杂访问虚基类成员往往比普通继承多走一层间接运行效率稍微下降。更重要的是虚基类的构造责任转移给了最派生类。也就是说当DogBird被构造时Animal的构造函数由DogBird主动调用而不是由Dog或Bird调用class Animal { public: Animal(int age) {} }; class Dog : virtual public Animal { public: Dog() : Animal(1) {} // 这个不会在DogBird中被自动转调 }; class DogBird : public Dog, public Bird { public: DogBird() : Animal(2), Dog(), Bird() {} // 最派生类负责构造虚基类 };这就很反直觉Dog构造函数里明明写了Animal(1)但你在构造DogBird时那个调用被忽略DogBird必须先调用Animal(2)。如果你忘了在DogBird里初始化虚基类而Animal又没有默认构造编译直接报错。6.4 虚继承的应用现状与取舍虚继承在公司项目里其实不算常见除非你做的框架类库需要用多继承做混入。标准库里有一个近似的例子iostream继承自istream和ostream二者又虚继承自ios_base目的就是让流对象只保留一份公共信息。日常业务代码里遇到菱形继承的机会不多一旦遇到优先可以考虑用组合或者接口转发来规避菱形结构比直接上虚继承更简单可控。真要用虚继承记得遵守最派生类负责构造虚基类这条铁律。7. 继承还是组合架构选择的取舍与反思7.1 组合优于继承到底是什么意思设计模式那本经典书提出了一句话优先使用对象组合而不是类继承Favor composition over inheritance。但在国内教学里很多课程把继承讲成了面向对象的标配导致不少初学者走出校门写代码时第一反应就是继承。实际上继承是一种强耦合关系子类改动会牵连父类父类改动会影响所有子类而且这种影响在编译期就固定了非常难以调整。组合的意思是你通过持有另一个类的对象来获得能力class Penguin { public: void swim() { std::cout 企鹅游泳\n; } private: // 企鹅不需要继承Bird它可以拥有一些通用行为对象 Flipper flipper_; };组合的耦合是松的你内部用什么实现随时可以换外部接口不变。而且组合天然支持多重能力——一个类可以拥有多个成员对象对应多个能力而继承想获得多个能力就得引入多继承复杂度陡增。7.2 Liskov替换原则继承关系的试金石Barbara Liskov提出的替换原则说得很直白如果一个类型S是类型T的子类型那么在程序里所有使用T的地方都应该能无缝替换成S程序行为不被破坏。放到C里就是public继承必须保证Dog一定能当Animal用。反例就是企鹅。生物学里企鹅是鸟鸟会飞于是你写了class Bird { public: virtual void fly(); }; class Penguin : public Bird { public: void fly() override { throw std::runtime_error(企鹅不会飞); } };编译没问题但你破坏了替换原则所有依赖Bird会飞的代码比如一个letItFly(Bird b)函数传入Penguin就会运行期炸掉。企鹅不是不能继承Bird但飞这个能力不该放在Bird这个抽象里。更合理的设计是把会飞拆出来class Bird { /* 通用的鸟类特征 */ }; class Flyable { public: virtual void fly() 0; }; class Sparrow : public Bird, public Flyable { /* ... */ }; class Penguin : public Bird { /* 不会飞不实现Flyable */ };每次写继承时拿Liskov原则问自己子类会不会在某些场景下做不到父类承诺的事只要有一个会就别用这层继承。7.3 判断用继承还是组合的几条实用标准我在设计类关系时的自检清单是这样的是不是严格的is-a关系如果不是哪怕是很像优先组合。子类是否会完全复用父类的接口如果只想复用一部分用组合或者private继承更稳妥。你需不需要多态如果需要通过基类指针调用不同子类实现那继承通常配合虚函数是不可替代的。继承层级会不会超过两层三层以上就要警惕继承链越长大家都动不了这根链上的任何一个类牵一发而动全身。这时候通常应该回头审视抽象是否合理。父类的改动对子类的影响是否可控继承把子类和父类绑死在编译期而组合可以通过接口隔离变化。说到底继承不是装饰门面的概念它是一把非常锋利的手术刀。用得准能切开复杂系统的心智负担用得滥就是把所有类焊死在一起后续每加一个功能都是拆弹。7.4 一个实际的取舍案例早期我做图形编辑器时设计过一个Rect类后来需要填充颜色就写了个FilledRect继承Rect再后来又要描边又写了个StrokedFilledRect继承FilledRect。三层继承下来构造参数变得极其臃肿而且Rect改一个构造参数下面三个类全都得跟着改。后来我重构了一下把它们改成组合图形元素持有多个可选的样式组件填充、描边、阴影每种样式是独立的类。改动之后新增一种圆角描边只需要加一个样式组件完全不动原有类。这个经历让我彻底记住了继承适合表达稳定的类型层级组合适合处理能力随需求变化的场合。最后再说几句实操体会写了这么多年C踩过用完继承找不着北的坑也尝过用抽象基类把系统收拾得妥妥当当的甜头。要我说学继承这件事最该养成的习惯就是动手前先问为什么为什么这个类要继承那个类这个关系是is-a吗父类析构是不是虚的传参是不是用指针或引用这些问题在面试里问出来不稀奇真正重要的是在写每一行业务代码时也保持警惕。我自己的第二个习惯是凡是打算做基类的类第一件事就写virtual ~Class() default;省得以后哪天子类扩展了资源管理回头补虚析构时再排查一遍内存泄漏。继承玩明白了再看STL里的iterator、iostream这些继承设计你会越看越有味道因为这里面的每个冒号背后都是前人深思熟虑后的取舍。这篇就当是把我在继承这条路上摔过的跤、翻过的车都倒给你了剩下的得你自己去代码里动手验证。