封装不当本质是接口设计与责任划分偏差:暴露不足需提供明确配置入口并校验前移;隐藏过度应简化调用链、用record替代冗余DTO;保护失效须改用不可变类型与防御性拷贝;职责错位要拆分校验、通知等逻辑至专用类。

封装不当不是“没加 private”,而是接口设计和责任划分出了偏差——该暴露的不放,该藏住的没藏,或者用一堆壳把逻辑裹得谁也看不懂。改起来不靠加修饰符,而要回到业务意图和协作关系本身。
暴露不足:核心字段或配置被锁死,业务扩展寸步难行
比如上传工具类把存储路径、超时时间全设为私有且无 setter,新需求一来只能重写。这不是安全,是阻碍。
- 保留必要配置入口:提供 setStoragePath()、setTimeout() 等明确命名的方法,而非开放整个内部对象
- 校验前移:在 setter 中做参数检查(如路径合法性、超时范围),而不是等运行时报错
- 默认值 + 显式覆盖:构造时设合理默认,允许按需调整,不强求“一次初始化定终身”
隐藏过度:简单数据硬套多层包装,调用链长得像迷宫
一个获取支付时间,要走 User → Order → Payment → getTime(),中间还夹着几个空壳 Wrapper 类。这不是封装,是绕路。
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 用 record(Java 14+)替代 DTO 类:一行定义
record PaymentTime(Instant paidAt) {},语义直白,不可变,无冗余方法 - 分页、响应结构等通用形态,统一用泛型类(如
Page<T>),不为每个业务建PageUser、PageOrder - 避免 “DataWrapper → ResponseWrapper → ApiResult” 这类叠床架屋,字段名直接说清用途(
success、data、errorDetail)
保护失效:用了 private 却挡不住外部篡改
Date 类型就是典型——字段 private,但传入的 Date 对象被外部调用 setTime(),内部状态瞬间被污染。
立即学习“Java免费学习笔记(深入)”;
- 改用 java.time 不可变类型:
Instant、LocalDateTime,所有“修改”都返回新实例,原始值不受影响 - 对可变集合做防御性拷贝:
this.permissions = new ArrayList(permissions),不直接引用传入列表 - 构造函数中避免调用非 final 方法,防止子类在父类未初始化完就介入
职责错位:一个类既管数据、又管校验、还管发短信
把用户信息、地址校验、通知发送全塞进 User 类,表面“高内聚”,实际是高耦合——改个校验规则,得动测试、改日志、碰通知逻辑。
- 拆出独立校验器:
AddressValidator负责验证,User只负责持有结果或委托调用 - 跨域操作交给专用服务:
NotificationService处理发送,User不感知渠道细节 - 拒绝“大管家类”:一个类只做一件事,名字能说清它该干什么(如
UserProfile不该包含sendWelcomeEmail)

















