封装的核心是约束与责任划分，通过私有化字段并提供公共方法控制访问，确保对象始终处于合法状态，如用户余额需由账户对象自身管理增减操作。
封装不只是把字段设为 private 再加个 getter/setter。它的真正作用是控制访问、隐藏实现细节、保护数据一致性，让对象对外提供清晰稳定的行为接口，而不是暴露内部结构。
1. 封装的核心：约束与责任划分
在业务开发中，很多问题源于数据被随意修改或状态不一致。通过封装，我们能确保对象始终处于合法状态。
比如用户余额字段，不能直接 public 让外部随意增减。应该由账户对象自己管理：
private BigDecimal balance = BigDecimal.ZERO;
public void deposit(BigDecimal amount) {
if (amount.compareTo(BigDecimal.ZERO) <= 0) {
throw new IllegalArgumentException("存款金额必须大于0");
}
this.balance = this.balance.add(amount);
}
public void withdraw(BigDecimal amount) {
if (amount.compareTo(BigDecimal.ZERO) <= 0) {
throw new IllegalArgumentException("取款金额必须大于0");
}
if (balance.compareTo(amount) < 0) {
throw new IllegalStateException("余额不足");
}
this.balance = this.balance.subtract(amount);
}
public BigDecimal getBalance() {
return balance; // 只读暴露
}
这样外部无法绕过校验逻辑直接操作 balance，避免非法状态。
立即学习“Java免费学习笔记（深入）”；
2. 封装复杂逻辑：对外简化调用
业务中常有组合操作，比如“下单并扣库存”。如果不封装，每个调用方都要重复写事务、校验、状态变更等流程，容易出错。
更好的方式是在订单服务类中封装整个流程：
public class OrderService {
private InventoryService inventoryService;
private OrderRepository orderRepository;
public Order placeOrder(OrderRequest request) {
validateRequest(request);
checkInventory(request.getItems());
Order order = createOrder(request);
reduceInventory(request.getItems());
orderRepository.save(order);
return order;
}
private void validateRequest(OrderRequest request) { ... }
private void checkInventory(List<Item> items) { ... }
private void reduceInventory(List<Item> items) { ... }
}
调用方只需一句 orderService.placeOrder(request)，无需了解背后逻辑。这就是封装带来的可维护性和复用性。
3. 封装状态变化：用行为代替字段操作
常见误区是把所有状态字段暴露出来，比如订单状态 status，然后外面一堆 if-else 判断能否发货、取消等。
正确做法是让订单自己决定能否执行某个动作：
public class Order {
private String status;
public void cancel() {
if (!canCancel()) {
throw new IllegalStateException("当前状态不允许取消");
}
this.status = "CANCELLED";
}
public boolean canCancel() {
return "UNPAID".equals(status) || "PAID".equals(status);
}
public boolean isShippable() {
return "PAID".equals(status);
}
}
这样状态流转逻辑集中在一处，后续扩展（如增加审批环节）只需改内部实现，不影响外部。
4. 封装边界：定义清晰的协作接口
在分层架构中，封装也体现在各层之间。比如 DAO 层封装数据库访问细节，Service 层封装业务规则，Controller 只负责协议转换。
每一层都对外隐藏实现，只暴露必要方法。例如 Service 不应返回 Entity，而是封装成 DTO 或聚合根，防止外部误操作持久化对象。
这种封装保障了系统模块间的低耦合，便于测试和演进。
基本上就这些。封装的本质不是语法限制，而是设计思维——让每个类对自己负责的数据和行为拥有控制权，对外提供安全、明确的服务。在业务代码中坚持这一点，能显著降低出错概率，提升代码可读性和可维护性。
