17370845950

封装的本质是保护不变量而非字段，需通过私有字段+带校验的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，而非暴露原始字段

封装最易被忽略的一点：它不保护字段，而是保护**不变量（invariant）**。一个 BankAccount 类可以有 private double balance，但真正要守住的是「balance 永远 ≥ 0」——这个约束必须嵌在所有可能改变它的方法里，而不是靠注释或文档提醒调用方。