盲目为每个私有变量添加get/set方法是封装的反模式，因其破坏访问控制、暴露内部状态、阻碍重构；应按需提供带校验或副作用的访问器，或以行为封装替代字段封装。
不是。给每个私有变量机械地配一对 get 和 set 方法，恰恰是封装的反模式。
为什么盲目写 get/set 是错的
封装的核心目标不是“把 public 变成 private 再加两个函数”，而是控制访问、保护不变量、隔离变化。一旦你为每个字段都暴露 getXXX() 和 setXXX()，就等于把私有字段的读写权原样交还给了调用方——和直接 public 几乎没区别，只是多了一层函数调用开销。
常见错误现象包括：
- 调用方绕过业务逻辑直接改
level_或score_，导致对象状态不一致 - 后续想把
std::string name_换成char name_[64]，所有调用getName()的地方都要重编译（因为返回类型变了） - 头文件里塞满几十个 trivial getter/setter，破坏接口清晰度，也拖慢编译
什么时候该提供 get/set
只在满足以下至少一条时才考虑加访问器：
-
get是只读且无副作用的（比如getName() const），且调用方确实需要这个值做外部计算 -
set带有意义的校验或副作用（比如setAge(int a)里检查a >= 0，或触发缓存更新） - 该字段属于稳定对外契约的一部分（例如协议字段、配置项），且未来不会重构存储方式
- 你需要支持序列化/反射等基础设施，但此时应由工具生成，而非手写
注意：const std::string& getName() const 比 std::string getName() const 更合理——避免不必要的拷贝；而 void setName(const std::string& n) 也比按值传参更高效。
替代方案：按行为封装，而不是按字段封装
与其暴露字段，不如暴露意图。例如：
- 不要提供
setLevel(int)和setScore(int)，而是提供promoteToVip()或applyBonus(int points) - 用户信息类不需要
getPhone()，但可以提供isContactable() const（内部判断 phone/email 是否非空） - 设备参数类不用为每个寄存器地址写 set/get，而应提供
readVoltage(Channel ch)和enableOverloadProtection(bool on)
这种设计让调用方只关心“做什么”，而不是“改哪个字节”。当业务规则变更（比如 VIP 升级从看 level 改为看 score+活跃度），你只需改一个函数体，外部代码完全不受影响。
动态参数场景下别硬套 get/set
如果设备参数数量多、类型杂、甚至运行时可变（比如通过配置文件加载），强行给每个参数写 getParamVoltAB() 这种函数既不可维护也不可扩展。这时更合理的做法是：
- 用
std::unordered_map<:string std::any></:string>（C++17+）或boost::any管理键值对 - 提供类型安全的模板接口：
template<typename t> T getParam(const std::string& key) const</typename> - 关键参数仍走强类型接口（如
getTemperatureCelsius()），其余辅助参数走泛型接口
重点在于：泛型接口是补充，不是替代。它解决的是“不确定有多少参数”的问题，而不是“懒得设计接口”的借口。
真正难的从来不是写多少个 get 和 set，而是判断哪些字段值得被访问、以什么方式被访问、以及当它们背后的实现换掉时，接口还能不能稳住。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
