Google C++风格指南基类成员规则疑问：为何数据成员需设为private而非protected

这个问题问得特别到位——不少刚摸C继承的开发者都会纳闷：为啥非得搞getter/setter这么麻烦，直接把数据成员设成protected让子类用不香吗？咱们结合Google C风格指南的核心思路，掰扯清楚背后的门道：

• 封装性与接口稳定性是核心
  把数据成员设为private，意味着父类A完全掌控了m的访问逻辑。哪天你要是想修改m的存储方式——比如从double改成两个float拼接，或者加个缓存逻辑减少计算量——只需要修改getter/setter的实现就行，子类B半毛钱都不用改。但要是把m设成protected，子类直接硬编码访问m的话，A的内部实现一变，所有用了m的子类都得跟着改，这就把父子类的耦合度拉得极高，后续维护简直是噩梦。

• 防止子类意外破坏父类状态
  protected数据成员相当于给子类开了个“直通内部的后门”，子类可以随便改它，很容易违反父类原本的状态约束。比如假设m代表的是一个非负数的阈值，A的setter里会做合法性检查，但子类要是直接改m，很可能把它设成负数，直接搞崩A的逻辑。用getter/setter的话，A可以统一管控所有对m的修改，保证自身状态的一致性，不会被子类的操作搞乱。

• 依赖关系更清晰，符合面向接口编程
  子类通过getter/setter访问父类成员时，依赖的是父类的公开接口而非内部实现细节。这让代码的依赖关系一目了然——子类只需要知道A能提供什么操作，不需要关心A内部怎么存数据。这种设计也更贴合“面向接口编程”的思想，让代码更容易扩展和维护。

回到你的例子，正确的做法确实是给类A的m实现protected的getter/setter函数（比如protected: double getM() const; void setM(double val);），这样类B就能安全地访问和修改m，同时又不会破坏A的封装性。

内容的提问来源于stack exchange，提问作者user2416984