C++封装要求将数据和操作绑定在class中并设为private，以通过编译期访问控制确保逻辑完整性；struct或全局变量破坏该约束，导致状态失控；.h/.cpp分离旨在隐藏实现、稳定接口。

应该放在一起——这是 C++ 封装的底层要求，不是风格偏好，不这么做会直接导致访问失控、逻辑脱节或维护灾难。

为什么 class 而不是 struct 或裸函数 + 全局变量

把数据和操作绑在 class 里，核心是控制访问路径。C++ 默认所有成员是 private，意味着你无法绕过类提供的接口去读写内部状态。而用 struct（默认 public）或全局变量 + 独立函数，等于把钥匙扔在地上：

• BankAccount 的 balance 如果是全局变量，任何地方都能 balance = -1000;，没人拦得住
• 如果 deposit() 是独立函数，它无法天然绑定到某个 BankAccount 实例，调用时必须手动传参，容易传错对象、漏校验、重复写边界逻辑
• class 把 balance 和 deposit() 绑定后，account.deposit(100) 这一调用本身就隐含了“对谁操作”和“按什么规则操作”两个约束

public/private 划分不是摆设，是强制契约

很多初学者把所有成员都设成 public，以为“放一起”就完事了。其实没用——封装失效的关键就在这一层。真正起作用的是访问控制带来的编译期约束：

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

• private 成员只能被本类的成员函数或友元访问，编译器会报错： error: 'balance' is a private member of 'BankAccount'
• getBalance() 可以加日志、做单位转换、触发缓存更新；deposit() 可以检查金额正负、记录流水、通知监听器——这些逻辑一旦散落在外部函数里，就再也无法随对象生命周期自动生效
• 如果你发现某个 private 成员“总得临时放开访问”，大概率是设计问题：要么该成员不该私有（应重构为 protected 或提供受控接口），要么调用方本就不该知道这个细节

分离实现时，.h 和 .cpp 文件怎么分工

把声明和定义拆到不同文件，不是为了“分开”，而是为了隐藏实现细节，同时保持接口稳定：

立即学习“C++免费学习笔记（深入）”；

• MyClass.h 只暴露 public 接口：类声明、公有函数原型、public 成员变量（极少）、#include 依赖
• MyClass.cpp 实现所有函数，包括访问 private 成员的逻辑；这里可以加 static 辅助函数、用未公开的结构体，外部完全不可见
• 改动 MyClass.cpp 里的私有实现，只要 .h 不变，所有使用它的代码都不需要重新编译
• 别在 .h 里写 private 成员的具体类型（比如 std::vector<Detail>），改用 pimpl 惯用法或前向声明，否则头文件一动，全项目重编译

真正难的不是“放一起”，而是判断哪些东西该放进类、哪些该留在外面。一个 private 成员如果只被一个 public 函数读写，又不参与构造/析构逻辑，那它大概率属于这个类；但如果十个函数都在反复修改它、还常要跨类同步，就得考虑是不是抽象错了——这时候“放一起”反而掩盖了职责混乱。