《你真的了解C++吗》No.027：访问权限：不仅仅是访问控制——受保护成员的语义陷阱
《你真的了解C++吗》No.027：访问权限：不仅仅是访问控制——受保护成员的语义陷阱
导言：封装的灰色地带
在 C++ 中，protected的初衷是提供一种“温和的封装”：它对外界保持封闭，但对子类保持开放。这种设计初衷是好的，但在实际的物理规则下，它引发了一个让无数初学者甚至老手都感到困惑的访问限制。
一、 语义陷阱：谁能访问谁的protected？
请看这个经典的案例，它揭示了 C++ 权限控制中一个非常冷酷的逻辑：
classBase{protected:intvalue;};classDerived:publicBase{public:voidtest(Derived&d,Base&b){d.value=10;// 成功！通过派生类对象访问自己的成员b.value=10;// 错误！编译失败：不能访问基类对象的受保护成员}};物理真相：
派生类只能访问**“属于自己那一部分”**的基类成员。编译器禁止你通过基类指针或对象去访问protected成员，是为了防止以下情况：
如果你能通过Base& b修改value，那么我只需要写一个临时类class Hack : public Base，就可以在Hack内部随意修改全世界任何一个Base对象（甚至是Derived以外的其他子类对象）的私有保护数据。这会导致封装性彻底崩溃。
二、protected成员：维护性的灾难
在架构设计上，protected成员其实是**“针对派生类的公有接口”**。
- 承诺的枷锁：一旦你把一个成员变量设为
protected，你就相当于向所有未来的子类承诺：这个变量的名字、类型和含义将永远不变。 - 重构困难：如果你某天想把这个变量从
int改成double，或者想彻底删除它，你会发现你需要翻遍整个工程，修改所有继承自你的类。
底层建议：永远不要把数据成员设为protected。如果你想让子类访问，请提供protected的Getter/Setter函数。这样当你改变内部实现时，至少可以保持函数接口不变。
三、 权限的“过滤器”效应
我们在 No.023 聊过私有继承，现在我们从物理布局的角度总结一下三种继承方式如何过滤基类成员的可见性：
| 基类成员类型 | public 继承后 | protected 继承后 | private 继承后 |
|---|---|---|---|
| public | public | protected | private |
| protected | protected | protected | private |
| private | 不可见 | 不可见 | 不可见 |
物理本质：
继承方式实际上是规定了基类成员在派生类中的上限可见度。
public继承：保持原样（Is-a 关系）。private继承：将所有基类特征“漂白”为私有，这通常意味着你终结了该类进一步被他人继承并利用基类功能的可能性。
四、 现代 C++ 的观点
在现代 C++ 的设计哲学中，大家倾向于：
- 要么 public：纯粹的接口。
- 要么 private：彻底的封装。
- 尽量不用 protected：因为它往往意味着设计上的模棱两可。
总结：防线的选择
public：展示给全世界看的“脸面”。protected：只传给后代的“家传秘籍”，但即便在家里，你也不能去动长辈的东西。private：只有自己知道的“心事”，连后代都无法窥探。
下一篇预告：既然封装防线如此严密，有没有一种“后门”，可以让一个完全无关的类直接翻墙进入你的私有领地？
➡️《你真的了解C++吗》No.028：友元（friend）的必要性与边界——为什么它不是对封装的破坏？