封装应服务于可读性与可维护性，而非堆砌修饰符或强行拆分；按需封装、职责单一、用组合替代嵌套、合理使用工具类，才是本质。
封装本身不是问题，问题出在“为封装而封装”——比如一个只读字段硬加 private + getter，或者把三行逻辑塞进六层嵌套类里。避免冗长的关键，是让封装服务于可读性与可维护性，而不是堆砌访问修饰符或强行拆分。
按需封装，不预设边界
不要一上来就给每个字段加 private、写全套 getter/setter。先问：这个字段会不会被外部修改？有没有业务规则要校验？如果只是内部计算用的临时值，甚至可以考虑 package-private（默认访问权限）+ 注释说明用途。
- 只读属性 → 只提供 getter，不写 setter
- 构造即确定的值 → 用 final 字段 + 构造器注入，省去 setter 和空校验
- 纯数据载体（如 DTO）→ 若框架要求，用 Lombok @Data 生成必要方法；否则直接用 record（Java 14+），一行定义，语义清晰
封装粒度匹配职责范围
一个类该封装多少，取决于它承担的职责是否单一。把“用户信息”“地址校验”“短信发送”全塞进 User 类，再用 private 方法层层调用，表面封装了，实际把逻辑耦合得更紧。
- 把校验逻辑抽成独立的 Validator 类，User 只持引用或接收结果
- 发送通知这类跨域操作，交给专门的 NotificationService，User 不感知实现细节
- 避免“大管家类”：一个类既管数据、又管格式化、又管持久化、还管日志，这种封装只会让代码越来越厚
用组合替代嵌套式封装
过度设计常表现为层层包装：DataWrapper → ResponseWrapper → ApiResult → GlobalResponse。与其用继承/包装强推统一结构，不如用组合明确协作关系。
- 返回结果用 record 或简单 POJO，字段名直白（如 success、data、errorMessage），不套壳
- 需要扩展时，靠字段组合（如加 traceId 字段），而不是新增一层 Wrapper 类
- 通用结构（如分页）用泛型 + 独立类（Page
），而非为每种业务对象定制 PageUser、PageOrder 等子类
工具类和静态方法不是敌人
封装不等于必须建新类。字符串判空、金额格式化、时间偏移计算……这些无状态、高复用逻辑，放在 public static 工具方法里，比塞进某个业务类的 private 方法更轻量、更易测试、更易复用。
- 命名清晰（如 StringUtils.isBlank()、MoneyUtils.formatYuan()）
- 不依赖实例状态，不持有上下文
- 避免“伪封装”：把工具方法硬塞进某个业务类里，只为凑满 private 方法数
封装的本质是控制可见性与责任归属，不是给代码加衣服。写完一段封装，不妨自问：别人看这三行，能不能一眼看懂“它做什么、为什么这么封、改起来难不难”——能，就到位了；不能，就该删减或重理。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
