Java封装性在面向对象编程中的重要性_技术教程

封装的本质是保护不变量而非字段，需通过私有字段+带校验的getter/setter、只读设计、合理使用package-private/protected等手段，在最小必要可见性下确保业务约束。

Java 封装性不是语法糖，是控制权的交接仪式——把数据的修改权从调用方手里收回来，交还给类自己。

为什么 `private` 字段 + `public` getter/setter 不等于封装？

很多人以为加了 private 和一对 getX()/setX() 就完成了封装，其实只是披了层皮。真正封装的关键在于「是否保留校验、转换、副作用的入口」。

setAge(int age) 如果只是无脑赋值，那和直接暴露 public int age 在逻辑上没区别——外部仍能传入 -5 或 200

真正的封装要让 setAge() 成为唯一合法入口，并在里面做边界判断：

public void setAge(int age) {
    if (age < 0 || age > 150) {
        throw new IllegalArgumentException("Age must be between 0 and 150");
    }
    this.age = age;
}

更进一步：如果年龄变化需要同步更新 isAdult 字段，这个联动逻辑必须藏在 setAge() 内部，而不是让调用方手动维护

什么时候该拒绝提供 `setter`？

封装的终极形态是「只读」——一旦对象创建完成，某些状态就不该再被外部篡改。这不是保守，而是表达业务约束。

身份证号、订单号、创建时间等具有唯一性或不可变性的字段，应只提供 getter，构造时通过参数注入
使用 final 修饰字段（如 private final String id;），配合全参构造器，编译期就能阻止误改
若需“逻辑上可变但不允许直接设值”，可用 builder 模式或专用方法替代通用 setter，比如 markAsShipped() 而非 setStatus("SHIPPED")

`package-private`（默认访问）比 `private` 更适合哪些场景？

封装不是越严越好，而是「最小必要可见性」。过度使用 private 会导致测试困难、扩展僵硬、内部复用断裂。

工具类中供同包内其他类复用的辅助方法，用默认访问比 private 更合理；否则只能提成 public，破坏边界
JUnit 测试类与被测类同包时，可直接访问 package-private 方法验证中间状态，避免为测试暴露 public 接口
框架集成时（如 Spring 的 @Autowired 注入 package-private 字段），默认访问提供了可控的“松耦合入口”

继承关系下，`protected` 是封装的缺口还是桥梁？

protected 不是封装的倒退，而是把控制权有节制地移交给了子类——它要求父类明确声明：“这部分逻辑允许被重写，但仅限于我的后代。”

滥用 protected 字段等于开放内存地址：子类可任意读写，父类无法干预，违背封装本质
正确做法是把可变行为抽象为 protected 方法（如 protected void onInit()），字段仍保持 private，子类只能通过钩子参与流程，不能绕过校验
如果子类需要读取某个计算结果，应提供 protected final getter，而非暴露原始字
段