封装的核心是访问控制与接口抽象，而非仅将函数放入class；必须将成员变量设为private并提供受控的public函数访问，struct显式加private同样可实现封装。
封装不是“把函数塞进class里”就完事了
封装的核心是访问控制 + 接口抽象，而不是语法上把函数写在class花括号里。你完全可以在class里定义一堆public函数和public成员变量，那只是“有类的壳”，没封装——外部代码照样能绕过函数、直接读写变量，等于白干。
真正封装必须满足两个条件：成员变量得是private（或至少不公开），且提供受控的public成员函数来间接访问。否则，class和struct在行为上没区别，连private都不加，那跟C语言的struct加几个函数指针也没本质差异。
class里放函数 ≠ 封装，struct里放函数也可能封装
C++中struct和class只差一个默认访问权限：class默认private，struct默认public。但只要你显式写上private:，struct一样能封装：
struct Box {
private:
double length, width, height;
public:
void set(double l, double w, double h) {
length = l; width = w; height = h;
}
double volume() const { return length * width * height; }
};这段struct代码和等价的class版本在封装效果上完全一致。关键不在关键字，而在你是否主动隔离了数据与外部直接接触。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
成员函数调用时隐含this指针，这是封装的运行基础
当你写box.set(1.0, 2.0, 3.0)，编译器实际调用的是Box::set(&box, 1.0, 2.0, 3.0)——this指针自动传入，让函数知道操作的是哪个对象的私有成员。这个机制让同一份函数代码能安全作用于不同实例，而无需暴露成员地址。
容易踩的坑：
- 在
private成员函数里误用this->去访问另一个对象的私有成员（非法，this只指向当前对象） - 把本该是
const的访问函数（如get_volume()）漏写const，导致无法在const对象上调用 - 在构造函数里调用虚函数，此时
this指向的对象尚未完全构造，虚表还没就位，行为未定义
不封装的“类函数”会破坏可维护性和二进制兼容性
如果把所有成员都设为public，外部代码就会形成对内存布局的强依赖。比如你改了class Person里string name和int age的声明顺序，或者加了个新字段，所有直接访问p.name或取地址&p.age的代码都可能出问题——这不是逻辑错误，而是ABI层面的断裂。
而真正封装后，接口稳定在函数签名上：p.get_name()和p.set_age(int)内部怎么存、怎么算，外部根本不知道也不需要知道。哪怕你把age从int换成std::optional<int>，只要函数行为不变，调用方完全无感。
这点在动态库、跨团队协作或长期维护项目里特别关键——封装不是为了“看起来高级”，是给变化留出安全缓冲带。
