对象状态管理的核心是封装：状态字段私有化、禁用裸赋值、变更通过受控方法（如withdraw）实现；复杂状态用状态模式或枚举管控；不可变对象为终极防护。
对象状态管理的核心是把数据和操作数据的方法绑定在一起，通过封装控制外部对状态的直接访问，只暴露安全、有意义的接口。
状态应该私有化，禁止外部直接读写
类的字段（尤其是表示状态的变量）必须用private修饰，避免被外部随意修改导致不一致。比如一个银行账户余额，不能让调用方直接执行account.balance = -1000。
- 所有状态字段声明为private
- 不提供公开的setter方法，除非业务明确允许修改且有校验逻辑
- 如需读取，提供带语义的getter（例如isOverdraft()比getBalance()更能表达意图）
状态变更必须走受控方法，而非裸赋值
对象行为应驱动状态变化，而不是反过来。比如“取款”是一个行为，它内部判断余额、扣减金额、更新状态、记录日志——这一连串动作构成原子性操作。
- 把状态变更逻辑封装进方法，如withdraw(double amount)
- 方法内做完整校验（如金额是否为正、是否超余额）和副作用处理（如触发事件、更新时间戳）
- 避免在方法外用多个setter拼凑出非法中间状态（如先设status = "PR
OCESSING"再设result = null）
必要时引入状态模式或有限状态机
当对象有明显生命周期和多种互斥状态（如订单：待支付→已支付→发货中→已完成→已取消），硬编码if-else判断易出错且难维护。
- 用enum定义清晰的状态集合（如OrderStatus.PAID, OrderStatus.SHIPPED）
- 状态流转通过明确方法控制（如order.ship()只在PAID状态下生效）
- 复杂场景可引入状态模式：每个状态作为独立类，封装该状态下允许的行为
不可变对象是终极状态防护手段
如果对象创建后状态永不改变（如String、LocalDateTime），就彻底规避了并发和误修改问题。
- 所有字段final + private
- 构造器完*部初始化，不提供任何修改方法
- 如需“变化”，返回新对象（如new Person(name, age + 1)）
- 适合配置类、DTO、领域模型中的值对象
基本上就这些。状态不是越透明越好，而是越可控越安全。封装不是为了隐藏，是为了建立契约——告诉别人“你能做什么”，而不是“你里面有什么”。
