面向对象编程这部分我在《C Primer》上前后翻了两遍每次都觉得自己懂了等实际去写类、去搭继承体系、去调多态的时候才发现还有一堆细节没有摸透。这篇笔记把我在学习类、继承、多态这一串知识时的理解、验证过程和踩坑记录整理出来主要面向已经会用 C 写简单程序、但想系统把 OOP 这块补齐的读者。1. 从struct到class先把类的骨架搭对1.1 访问控制public、protected、private 不是装饰品很多初学者容易把 struct 和 class 混着用觉得差别就是一个默认 public 一个默认 private。但真正写起代码来访问控制是面向对象封装的第一道防线。《C Primer》里用 Sales_data 这个类一步步演示了怎么把成员变量收进 private、把接口暴露成 public这个过程看起来简单实际落地的时候有几个容易被忽略的细节。第一个细节struct 和 class 的区别。两者唯一区别是默认访问级别struct 默认 publicclass 默认 private。但在实际工程里struct 一般约定俗成用来表示“纯数据聚合”比如坐标、配置项、消息体class 用来表示“有行为的对象”。这个约定不是语言强制是团队风格但建议遵守否则读到代码的人会困惑。第二个细节友元到底要不要用。《C Primer》里反复强调友元会破坏封装但它又是一个合法特性。我自己的经验是友元只用在“两个类确实需要深度协作”的场合比如容器类和它的迭代器之间避免为了访问私有成员而把本该私有的东西全部改成 public。如果只是为了让一个外部函数读两个私有成员建议先考虑这个函数是不是应该设计成成员函数。第三个细节是访问控制和类的布局无关。private 成员并不是被藏起来了它只是编译器拒绝直接访问。用调试器照样能看到用指针偏移照样能改。所以不要把访问控制当安全机制它是约束程序员错误操作的设计规范。下面是一个典型的类骨架注意构造函数、访问级别、接口设计这几块class SalesData { public: // 构造函数 SalesData() default; SalesData(const std::string isbn, double price) : bookNo_(isbn), revenue_(price) {} // 接口 const std::string isbn() const { return bookNo_; } double avgPrice() const { return unitsSold_ 0 ? 0.0 : revenue_ / unitsSold_; } // 友元只给需要访问私有成员的非成员函数开这个小口子 friend SalesData add(const SalesData lhs, const SalesData rhs); private: std::string bookNo_; unsigned unitsSold_ 0; double revenue_ 0.0; };1.2 构造函数初始化列表比函数体赋值更值得依赖《C Primer》第7章对构造函数做了非常细致的分类默认构造、带参构造、拷贝构造、委托构造、移动构造。每一种单独看都不难但放在一起最经常出问题的是“什么时候用初始化列表什么时候在函数体里赋值”。初始化列表的作用是初始化函数体里的是赋值这两者的区别在执行顺序上非常明显。const 成员、引用成员没有默认初始化的能力必须在初始化列表中完成初始化否则编译直接报错。类的成员按照声明顺序初始化而不是按照初始化列表的书写顺序初始化的这个顺序坑我踩过一次——两个成员互相依赖的时候画蛇添足地在初始化列表里把顺序写反结果运行结果完全不是预期。《C Primer》里有一句说得很好如果成员是 const 或引用它们必须被初始化。而如果类本身需要依赖某个成员完成另一成员的初始化这时候优先考虑用函数体赋值还是重新设计成员顺序不要硬靠初始化列表解决。委托构造函数是 C11 引入的实用写法。构造函数之间共享初始化逻辑时用委托可以避免代码重复class Screen { public: Screen() : Screen(80, 24, ) {} Screen(int w, int h) : Screen(w, h, ) {} Screen(int w, int h, char c) : width_(w), height_(h), bg_(c) {} private: int width_; int height_; char bg_; };委托构造的关键限制是被委托的构造函数先执行执行完后再执行当前构造函数体内的剩余语句。所以不要在初始化列表里同时初始化成员又委托另一个构造函数那是编译错误。1.3 拷贝控制三/五法则不是理论是切肤之痛类的拷贝控制成员包括拷贝构造函数、拷贝赋值运算符、析构函数以及 C11 后加入的移动构造函数和移动赋值运算符。《C Primer》用很大篇幅讲这块因为 C 不像 Java 那样有垃圾回收对象的拷贝、赋值、销毁都要自己负责任。三/五法则的内容很直接如果类需要自定义析构函数几乎一定也需要自定义拷贝构造和拷贝赋值。如果一个类管理了堆内存、文件句柄、网络连接这类资源编译器默认的逐成员拷贝只会把指针值复制一遍结果是两个对象指向同一块内存析构的时候 double free或者修改一个对象同样改了另一个对象的数据。我自己实际写代码时遇到过的情况是一个字符串包装类没有自定义拷贝构造和赋值放进 vector 后程序崩溃或内存报错。排查了一下午最后发现是默认拷贝把指针直接复制两个对象析构时释放了两次同一块堆内存。改成自定义拷贝构造、拷贝赋值、析构之后问题消失。带移动语义的写法要注意移动构造和移动赋值一般要配合 std::move 使用并且移动后的对象需要处于“有效但未指定”的状态。比如把源对象的指针置空这样才能保证源对象析构时不会二次释放资源。《C Primer》里给出的 StrVec 实现是很好的标准范本建议照着敲一遍。注意三/五法则的“五”并不是说每个类都必须实现全部五个成员。如果类不需要自定义析构那拷贝控制通常也不需要动如果类的所有成员都是可拷贝的基本类型或标准库类型默认行为完全够用。判断标准是“是否管理了非内存形式的资源”。2. 继承体系设计三种继承方式与派生类的正确写法2.1 继承方式的选择逻辑public 是“is-a”private 是“实现复用”C 继承有三个关键词public、protected、private。很多人知道区别是“基类成员在派生类里的访问级别变化”但实际设计类继承体系时选择哪个方式背后应该有不同的语义逻辑。public 继承表达的是“is-a”关系。派生类对象可以当作基类对象使用这是最常用、也最符合面向对象本意的继承方式。比如 Circle 继承 Shape因为圆是一种形状。只有在 public 继承下基类的 public 成员才是派生类的 public 成员外部才能通过基类指针调用派生类接口。protected 继承和 private 继承很多时候被忽略但它们解决的实际问题是“实现复用”而非“接口继承”。private 继承的常见场景是类希望复用基类的实现但不想暴露基类的接口给外部调用者。这在现代 C 中不太推荐用因为组合成员对象往往比私有继承更好而且不会带来继承特有的耦合问题。三种继承方式对基类成员访问级别的具体影响我整理过一张表继承方式基类 public 成员基类 protected 成员基类 private 成员public 继承派生类 public 成员派生类 protected 成员不可直接访问protected 继承派生类 protected 成员派生类 protected 成员不可直接访问private 继承派生类 private 成员派生类 private 成员不可直接访问为什么说 public 继承是首选因为只有 public 继承能保证“派生类对象可以被当作基类对象使用”这个语义也就是 Liskov 替换原则。如果用 private 继承从外部看继承关系完全是实现细节调用者根本不知道基类的接口这更像是一种组合关系。2.2 派生类构造函数先初始化基类再初始化自己的成员派生类构造函数的执行顺序是面向对象编程里最容易想当然的环节。很多人以为派生类构造函数先执行函数体其实顺序完全相反先执行基类构造函数再按声明顺序初始化派生类成员最后才进入派生类构造函数体。这个顺序决定了派生类构造函数必须在初始化列表中显式调用基类构造函数。如果基类没有默认构造函数派生类就必须把基类构造参数传上去否则无法编译。看一个典型的例子class Base { public: Base(int id) : id_(id) {} int id() const { return id_; } private: int id_; }; class Derived : public Base { public: // 必须显式把 id 传给 Base不能在函数体里给 Base 赋值 Derived(const std::string name, int id) : Base(id), name_(name) {} private: std::string name_; };这里如果把 Base(id) 拿掉编译器会找不到适合的 Base 默认构造函数直接报错。报错信息在大型项目里不太显眼容易让人误以为是“派生类构造函数写错了”其实是基类构造函数没有显式调用。另一个操作细节是当基类有默认构造也有带参构造而派生类没有在初始化列表写 Base() 时编译器会默认调用基类的默认构造函数。这个默认行为可能是对的也可能是陷阱——如果基类默认构造出来的状态并不完整派生类对象也会处于不完整状态。2.3 名字遮蔽与重定义继承里最隐蔽的坑派生类里定义了与基类同名的成员函数基类的同名函数不会自动变成重载集合而是被完全遮蔽。这是 C 与 Java 最大的不同点。Java 的重载规则在 C 继承体系里并不成立。class Base { public: void fun(int x) { /* ... */ } }; class Derived : public Base { public: void fun(double x) { /* ... */ } // 遮蔽了 Base::fun(int) }; Derived d; d.fun(10); // 调用的是 Derived::fun(double)10 被隐式转换成 double这个行为如果没意识到很容易让调用结果和预期不一致。调用 d.fun(10) 时编译器找到 Derived::fun 就停止了不会向上继续搜索 Base::fun。所以即使传入 10 这个 int匹配到的也是 Derived::fun(double)而不是 Base::fun(int)。如果没有隐式转换甚至可能直接编译失败。要解除这种遮蔽一是用 using 声明把基类版本引入派生类作用域class Derived : public Base { public: using Base::fun; // 让 Base::fun 参与重载决议 void fun(double x) { /* ... */ } };二是避免在派生类里写和基类无关的同名函数。如果确实需要重定义要明确区分“重定义”和“覆盖”的区别。覆盖只发生在虚函数上重定义则是普通成员函数的同名词遮蔽。《C Primer》把这一点列为继承初始化里的重点实际中我发现很多人把这两个概念混在一起导致虚函数该写 virtual 没写、不该写的却写了。3. 多态的核心虚函数与动态绑定的完整理解3.1 虚函数的底层机制一个虚表指针搞清楚动态绑定多态被称为 C 面向对象编程的三大特性之一但很多人只记住了“virtual 关键字加上基类指针调用派生类方法”不理解背后的机制。理解虚函数表才是真正掌握多态的关键。每个包含虚函数的类编译器都会生成一个虚函数表表中存储该类的虚函数地址。每个对象内部隐藏一个虚表指针指向该类的虚表。当通过基类指针或引用调用虚函数时编译器不是直接生成“调用基类函数”的指令而是通过对象的虚表指针找到实际类型的虚表再从表中取出函数地址进行调用。这个机制解释了三个问题第一为什么虚函数调用比普通函数调用慢一点点。因为多了间接寻址和查表的过程。在性能敏感的循环里高频调用虚函数会有可感知的开销。第二为什么构造函数里调用虚函数不会触发多态。因为对象在构造过程中虚表指针先指向基类的虚表基类构造函数执行完毕后才改为指向派生类的虚表。所以基类构造期间调用的虚函数永远解析到基类版本而不是派生类版本。第三为什么动态绑定只在“指针或引用”调用虚函数时生效。如果直接用派生类对象调用虚函数编译器在编译期就能确定目标函数不需要动态绑定。但通过基类引用或指针时对象实际类型要到运行时才能确定这时候才走虚表查地址。class Shape { public: virtual void draw() const { std::cout Shape::draw std::endl; } virtual ~Shape() default; }; class Circle : public Shape { public: void draw() const override { std::cout Circle::draw std::endl; } }; Shape* s new Circle(); s-draw(); // 输出 Circle::draw这段代码看起来简单但底层实际发生了s 指向的对象里有虚表指针指向 Circle 的虚表虚表的第一个槽是 Circle::draw 的地址调用时从这个槽取出地址跳转。3.2 虚函数的正确写法override、final 和默认实参《C Primer》第15章强调了一个现代 C 的规范所有重写基类虚函数的派生类函数都应该写上 override。这个关键字不是可有可无的装饰它是编译器的校验员。如果没有 override派生类不小心把函数签名写错了——比如少一个 const参数类型对不上——编译器不会把新函数当作重写而会生成一个全新的遮蔽函数。这种错误在代码评审里很难发现因为基类函数依然存在调用也不报错只会在运行时出现“调用了错误的版本”的问题。加了 override 之后签名不一致直接编译失败问题被挡在最前面。final 的用途是阻止进一步继承。类可以加 final虚函数也可以加 final。设计抽象接口时有时候希望实现类不要再被继承或者某个虚函数的实现不希望被下层覆盖这类需求用 final 表达比用注释表达更可靠。默认实参是虚函数里最容易被忽略的细节虚函数的默认实参按照静态类型解析。意思是如果基类虚函数声明默认参数为 1派生类重写时声明默认参数为 2通过基类指针调用时即使实际执行的是派生类的函数体使用的默认参数依然是基类的 1而不是派生类的 2。这个行为和虚函数的动态绑定构成了矛盾但默认实参是编译期确定的所以虚函数的默认实参不能依赖动态类型。最好的做法是不要在虚函数中依赖默认实参做关键逻辑或者干脆让基类和派生类使用完全相同的默认值。还有两个限制值得记住静态成员函数不能是虚函数构造函数不能是虚函数但析构函数可以且通常应该是虚函数。3.3 纯虚函数与抽象基类面向接口编程的入口纯虚函数是“接口设计”的体现。用 0 声明的虚函数不需要提供实现含有纯虚函数的类是抽象基类不能实例化。派生类必须覆盖所有纯虚函数否则派生类也是抽象类。抽象基类的价值在于定义一套交互协议而不是复用代码。比如设计一个日志系统定义 LogSink 抽象基类FileSink、ConsoleSink、NetworkSink 分别实现调用方只需要依赖 LogSink 这个接口不需要关心具体是什么输出设备。这是依赖倒置原则在 C 里的落地方式。《C Primer》里提到抽象基类的纯虚函数也可以有自己的定义但只能通过“类名::函数名”的形式显式调用不能通过对象调用。这个写法在析构函数里偶尔能派上用场——纯虚析构函数必须提供定义这算是一个特殊的极端情况class Base { public: virtual ~Base() 0; // 纯虚析构 }; Base::~Base() {} // 必须提供实现否则派生类析构时链接错误注意析构函数写成纯虚函数通常是为了让类变成抽象类但析构函数本身还是要有实现否则派生类对象销毁时无法正确调用基类析构部分。3.4 为什么析构函数必须是虚函数内存泄漏的隐形来源只要类被设计为基类析构函数就该是虚函数。这个法则背后是动态绑定的基本逻辑。当通过基类指针删除派生类对象时如果析构函数不是虚函数delete 调用的是基类版本的析构函数派生类部分的资源堆内存、文件句柄、锁资源完全没有机会释放但内存块本身又会被释放。这种不匹配行为的结果就是资源泄漏和未定义行为。一个很现实的例子某个开发者写了一个 Base 类里面根本没有虚函数一个小型工具类也暂时不需要多态但后来代码演进中有人继承了它且通过基类指针管理派生类对象。此时 Base 的析构函数不是虚函数delete 时派生类的清理逻辑一步都没有执行。所以我的操作建议是凡是定义了虚函数的类析构函数必须写上 virtual凡是作为基类的类也建议把析构函数声明为 virtual哪怕只有默认实现。class Base { public: virtual ~Base() default; // 其他接口... };写 default 而不是空花括号可以让编译器生成正确的默认析构行为同时避免手动实现带来的拷贝控制问题。4. 面向对象实战那些教程没写清楚的坑与最佳实践4.1 切片问题传值和容器存储是重灾区对象的切片slicing问题是 C OOP 里不分新老手都会踩的经典陷阱。当派生类对象被赋值给基类对象时派生类特有的部分被“切掉”对象变成了一个纯粹的基类对象。Circle c; Shape s c; // 切片s 是一个 Shape而不是 Circle std::vectorShape shapes; shapes.push_back(c); // 切片存储在 vector 里的是一个 Shape切片之后虚函数调用也无法触发多态因为对象类型已经被“裁剪”成了基类类型。这和通过指针或引用访问是本质区别。解决方式只有两种用指针或者用引用。更现代的做法是使用智能指针比如 std::shared_ptr 容器收集不同类型的派生类对象。在实际项目中我曾经看到某同事把多态对象存进了 std::vector 然后遍历调用虚函数发现所有对象都执行基类版本。排查了很久才发现不是虚函数写错而是存的时候就切掉了。这个问题一旦理解原理再遇到就能一眼识别。4.2 多重继承与二义性能不用就不用C 支持多重继承但多重继承带来的二义性问题让很多人头疼。《C Primer》第18章才专门讲多重继承说明这不是初阶内容。如果两个基类有同名成员派生类继承了两个同名版本直接调用这个成员时编译器报二义性错误。更麻烦的是菱形继承问题类 A 是基类B 和 C 都继承 AD 又继承 B 和 C。这时 D 中会包含两份 A 的成员产生数据冗余和潜在的二义性。C 提供了 virtual 继承解决菱形问题但 virtual 继承的初始化规则比较复杂——最派生类负责初始化 virtual 基类。我的个人建议是多重继承在绝大多数业务代码里都不是必需品。可以用接口类加组合的方式达到类似效果。如果确实需要多重继承尽量让多个基类之间没有任何共同祖先避免菱形结构。如果已经遇到菱形继承用 virtual 继承能解决问题但接手代码的人可能需要额外花时间理解。4.3 现代 C 对 OOP 的实践改进从裸指针到智能指针传统的面向对象编程教程往往用裸指针演示多态比如 new 一个派生类对象再用 delete 删除。现实是裸指针和手动 delete 带来的异常安全问题非常突出——如果在 delete 之前抛出了异常资源就泄漏了。现代 C 推荐的做法是使用智能指针。用 std::unique_ptr 或 std::shared_ptr 管理对象生命周期多态和资源管理解耦std::vectorstd::shared_ptrShape shapes; shapes.push_back(std::make_sharedCircle()); shapes.push_back(std::make_sharedRectangle()); for (const auto sp : shapes) { sp-draw(); }这种情况下即使某次 draw 抛出异常智能指针析构时也能正确释放对象且析构函数是虚的派生类资源释放也没问题。另一个现代 C 的重要改进是 default 和 delete 的显式使用。不让类被拷贝时用 delete 明确禁止比自定义一个 private 拷贝构造函数更清晰class NonCopyable { public: NonCopyable() default; NonCopyable(const NonCopyable) delete; NonCopyable operator(const NonCopyable) delete; };还有 override 和 final 的强制校验配合编译器警告信息能把大部分继承错误提前暴露出来。《C Primer》作为一本完善的教材在末尾的现代 C 特性里提到这些工具实际工程中它们的价值比想象中大得多。4.4 常见问题速查与排查思路最后把我在学习和实战中遇到的典型问题整理成一个速查表方便对号入座现象可能原因解决方案基类指针调用虚函数执行的是基类版本函数签名没对上没加 override检查虚函数签名加上 override 让编译器校验delete 基类指针程序崩溃或内存泄漏基类析构函数不是虚函数基类析构函数前加 virtual派生类构造函数报“没有匹配的构造函数”基类没有默认构造派生类没显式初始化基类初始化列表里加上 Base(...) 调用派生类对象赋值给基类对象后行为异常发生了对象切片改用引用、指针或智能指针多重继承下调用成员报二义性错误多个基类含同名成员显式指定基类作用域或重新设计继承体系容器里存储的派生类对象调用虚函数不是派生类版本容器元素类型是基类存储时已切片容器存储 smart pointer而非对象本身对象拷贝后析构时 double free管理资源但没实现拷贝控制遵循三/五法则实现拷贝构造和拷贝赋值排查继承和多态问题时有一个非常实用的顺序先看函数签名是否一致再看析构函数是否为虚然后看对象是值、指针还是引用。按照这个顺序能快速定位大部分问题。回头看这本《C Primer》的面向对象编程章节最厚的部分不是语法本身而是语法背后的设计意图和边界条件。类与封装的粒度、继承体系的层次、虚函数的接口语义、资源与拷贝控制的责任这些才是一个 C 开发者真正需要慢慢积累的地方。我在实际项目中见过把封装做成铁板一块导致无法测试的设计也见过继承层次深达七八层的代码最终没人敢改前者违背了接口设计的初衷后者掉进了过度抽象的陷阱。如果你正在学习这一章建议把书里的示例代码手敲一遍然后自己试着设计一个小项目——比如一个图形绘制程序或者一个简单的缓存系统——把类、继承、多态都放进去用一遍。踩过坑之后再回头看虚函数表的机制你会对这些设计有完全不一样的理解。