封装性本质是控制访问边界，需通过私有属性+校验型getter/setter、接口抽象、构造器/工厂封装、事件驱动实现解耦。
在 Java 中，封装性不是单纯把属性设为 private 再加几个 getter/setter 就完事的。它本质是“控制访问边界”，为解耦打下第一层结构基础——只有先藏好内部细节，外部才能不依赖具体实现。
用私有属性 + 受控访问方法定义稳定接口
把业务实体的关键字段（如订单状态、用户权限等级、库存数量）全部设为 private，不暴露原始赋值入口。对外只提供带校验逻辑的 setter 和语义明确的 getter：
- setOrderStatus(String status)：内部判断是否允许从“待支付”跳转到“已发货”，非法流转直接拒绝
- getAvailableStock()：返回扣除预占库存后的实时可用数，而非原始 stock 字段
- 避免出现
order.setStock(100)这类破坏业务规则的调用
把变化点抽成接口，让实现可插拔
识别模块中可能变动的部分（比如短信通道、支付网关、风控策略），为其定义接口，而不是直接 new 具体类：
- 声明
interface PaymentProcessor，含process(PaymentRequest req) - 不同银行/渠道实现各自版本：
AlipayProcessor、WechatPayProcessor - 业务服务类只持有
PaymentProcessor引用，运行时由框架注入具体实现 - 新增支付方式只需新增实现类+配置，不改原有服务代码
用构造器或工厂封装对象创建过程
避免零散的 new XxxService() 破坏模块边界。统一通过构造参数或静态工厂方法组装组件：
立即学习“Java免费学习笔记（深入）”；
- 服务类构造器接收其依赖的接口（如
OrderService(PaymentProcessor p, NotificationSender n)） - 或提供
OrderService.createWithDefaultConfig()工厂方法，内部完成依赖装配 - 这样业务模块不感知底层组件如何初始化，也不绑定具体类名
将跨模块协作转为事件驱动
模块间不直接调用对方方法（如 userModule.updateUserPoints()），而是发布领域事件：
- 订单支付成功后，发布
OrderPaidEvent(orderId, amount) - 积分模块监听该事件，执行自身逻辑；通知模块也监听，触发短信发送
- 两个下游模块完全不知道彼此存在，也不需要引用对方的类
- 新增“优惠券发放”模块？只需加一个新监听器，无需修改订单核心逻辑
