封装是“数据藏好+接口管严+逻辑守牢”的设计思维，解决协作演进中的修改权责与影响范围问题；直接public成员变量导致业务逻辑崩坏且难以维护。
封装不是加个 private 就完事了，而是把“数据藏好 + 接口管严 + 逻辑守牢”三件事串起来的设计思维。它解决的从来不是语法问题，而是“谁该改什么、怎么改才不崩、改了别人要不要重写”的协作与演进问题。
为什么直接 public 成员变量是危险操作？
你写一个 User 类，把 age 设成 public int age，外部代码就能写 user.age = -999 或 user.age = 300 —— 编译器不拦，运行时也不报错，但业务逻辑已经崩了。
更麻烦的是：一旦后续要加年龄校验、审计日志、或把 age 改成从出生日期动态计算，所有直接读写 age 的地方都得翻出来改，牵一发而动全身。
封装的最小可行实现：private + getter/setter
这是 Java 封装的基线动作，缺一不可：
-
private字段：切断所有外部直连路径（哪怕同包、子类也不行） -
publicgetter：只读暴露，命名必须是getXxx()（布尔类型可用isXxx()） -
publicsetter：写入入口，必须在方法体内做校验，而不是放任传参
public class User {
private String name;
private int age;
public String getName() {
return name;
}
public void setName(String name) {
if (name == null || name.trim().isEmpty()) {
throw new IllegalArgumentException("姓名不能为空");
}
this.name = name.trim();
}
public int getAge() {
return age;
}
public void setAge(int age) {
if (age < 0 || age > 150) {
throw new IllegalArgumentException("年龄必须在 0-150 之间");
}
this.age = age;
}
}
容易被忽略的三个关键点
很多同学写了 getter/setter 就以为封装完成了，其实以下三点常被跳过，导致封装形同虚设：
- 构造器里也必须走
setter：比如new User("Alice", -5)如果构造器直接赋值this.age = age，校验就失效了；应调用this.setAge(age) - getter/setter 不是摆设：如果业务上某字段只读（如创建时间
createTime），就只提供getCreateTime()，不写setCreateTime() - 引用类型要防御性拷贝：如果字段是
private List，getter 返回tags new ArrayList(this.tags)，避免外部修改原始集合
什么时候不该封装？或者说，封装的边界在哪？
封装不是越严越好。比如工具类中的静态常量（public static final String API_URL = "https://..."）就不需要 getter —— 它本就不该变，也没状态可隐藏。
再比如 DTO（数据传输对象）有时为简化序列化，会放宽为 package-private 字段 + Lombok 的 @Data，但这属于权衡取舍，不是放弃封装思想，而是把“校验和控制”移到了构建层（Builder）或验证层（@Valid）。
立即学习“Java免费学习笔记（深入）”；
真正难的不是写对private 和 setXxx()，而是每次新增一个字段时，能下意识问一句：“这个值谁有权改？改之前要卡什么规则？改之后要不要通知其他模块？”—— 封装的本质，是把这种思考变成肌肉记忆。 
