封装性是围绕业务语义组织接口、屏蔽技术细节，用业务动词命名方法、封装校验与状态流转、避免getter/setter、隐藏外部依赖、强化不可变性。
封装性在 Java 中不是单纯把字段设为 private 就完事，而是围绕业务语义组织接口、屏蔽技术细节，让调用方只关心“做什么”，不操心“怎么做”。关键在于：用业务动词命名方法、把校验/状态流转/外部依赖等内部逻辑收进类内部，对外暴露干净的契约。
用业务方法替代字段访问
避免提供 getXXX()/setXXX() 暴露数据结构。例如订单类不应暴露 getStatus() 返回原始字符串或枚举值，而应提供符合业务场景的操作：
-
❌ 不推荐：
order.getStatus() == OrderStatus.PAID—— 调用方硬编码状态判断，耦合实现 -
✅ 推荐：
order.canBeShipped()或order.requestRefund()—— 方法内部封装状态校验、时间约束、库存检查等逻辑
把校验和状态变更收进方法体内
业务规则（如“支付后 24 小时内可取消”“退款需原路退回”）不应散落在 Service 层，而应由领域对象自己控制：
- 在
cancel()方法里统一判断当前状态、时间窗口、是否已发货等条件 - 一旦通过，自动更新内部状态（如
this.status = CANCELLED）、记录取消时间、触发事件 - 调用方只需写
order.cancel();，不用管它查了哪些表、调了哪个风控接口
隐藏外部协作细节
当业务动作需要调用第三方（如发短信、查征信、扣款），不要把客户端或 HTTP 工具暴露给上层。而是：
- 在领域对象或其配套的领域服务中封装调用逻辑
- 将异常转化为业务异常（如
InsufficientBalanceException而非HttpClientException） - 必要时引入策略或工厂，让具体实现可替换（如不同支付渠道走不同网关），但接口保持业务含义不变
用不可变性 + 构造约束强化封装
对核心业务对象（如金额、身份证号、订单号），优先设计为不可变：
- 构造时强制校验（如正则验证手机号、金额不能为负）
- 字段全
final，不提供 setter - 返回新对象而非修改自身（如
money.add(another)返回新Money实例） - 这样连“误改内部状态”的可能性都被语法层面堵死
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
