数据封装不是简单复制数据库字段，而是建立有业务语义、边界清晰、可维护的映射关系：字段命名需语义化（如user、name、isdeleted），属性全private并受控访问，状态变更走专用方法，读写逻辑分离，区分持久化模型与业务模型，注解仅作映射桥梁而非模型契约。
数据封装不是把数据库字段简单复制到 Java 类里，而是建立有业务语义、边界清晰、可维护的映射关系。核心在于：字段命名不照搬表名，访问控制要严格，状态变更需受约束，读写逻辑要分离。
用有意义的类名和属性名替代原始表结构
数据库表名（如 t_user_info）和字段名（如 user_name、is_del）直接作为 Java 类名或属性名，会暴露存储细节，也违背业务表达。应按领域语言重命名：
- User（而非 UserInfo 或 TUserInfo）—— 表达“用户”这个业务实体
- name（而非 userName 或 user_name）—— 属性属于当前对象，无需前缀
- isDeleted（而非 isDel 或 deleted_flag）—— 布尔字段用 isXxx 形式，语义明确且符合 JavaBean 规范
- createdAt（而非 create_time）—— 使用驼峰 + 语义化时间描述，便于序列化和 API 返回
私有属性 + 受控访问器，禁止裸字段暴露
所有字段必须声明为 private，不提供 public 字段或无校验的 setter。getter/setter 不是摆设，而是封装逻辑的入口：
Java Development Manual
下载
Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...
- setter 中做基础校验（如手机号格式、邮箱合法性、非空约束）
- 敏感字段（如 password）的 setter 可触发加密，getter 返回 null 或占位符
- 状态字段（如 status）的修改应走专用方法（activate()、deactivate()），而非直接 setStatus(1)
- 避免链式调用破坏封装，例如不要写 user.setName("A").setEmail("B")，除非明确设计为 Builder 模式
区分「持久化模型」与「业务模型」，必要时拆分
一张表常承载多场景职责（如审计字段、版本号、冗余计数），但业务对象只需关注当前上下文需要的数据。强行让一个类承载全部字段，会导致职责混乱：
- 查询场景用 UserSummary（仅 id + name + avatar）
- 编辑场景用 UserEditable（含 name、email、phone，不含 createTime 等只读字段）
- 持久层用 UserEntity（含所有数据库列，配合 JPA 注解）
- 通过构造函数或静态工厂方法完成转换，例如 UserEditable.from(userEntity)，而非靠 setXXX 手动赋值
用注解和工具辅助映射，但不依赖它们定义模型
JPA 的 @Column(name = "user_name") 或 MyBatis 的
- 注解只负责「如何从 DB 拿数据」，不决定「对象该有什么行为」
- 避免在业务模型上加 @Entity 或 @Table —— 这会让领域对象被持久化框架绑架
- 使用 MapStruct 或 ModelMapper 做对象转换时，显式声明映射规则（如 password 不复制、createdAt 自动赋值），而不是靠字段名自动匹配
- 数据库字段变更（如 rename column）不应导致业务类编译失败，而应只改映射配置
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
