封装通过私有化实现细节、暴露稳定接口、禁止链式访问、依赖抽象而非实现、抽离横切关注点,使模块依赖可控稳定。

封装本身不直接“切断”模块依赖,但它让依赖变得可控、稳定、不易断裂。真正起作用的是:把“怎么用”和“怎么实现”分开——外部只依赖清晰定义的接口或契约,不感知内部结构变化。
用 private + 稳定 public 接口隔离实现变动
把字段、工具方法、构造细节设为 private,只暴露语义明确、职责单一的 public 方法(如 placeOrder()、cancelIfPending()),而不是裸露数据或操作路径。
- 用户类里把
orders列表设为 private,不提供getOrders()返回可变 List,而是提供addOrder(Order)、getActiveOrderCount()这类带业务含义的方法 - 修改订单状态时,不暴露
order.setStatus(STATUS_CANCELLED),而用order.cancel()封装校验逻辑(比如只能取消待支付订单) - 这样即使后续把订单存储从内存 List 换成数据库查询,或增加风控拦截,调用方代码完全不用改
避免跨层/跨域的链式访问
禁止出现 user.getProfile().getAddress().getCity() 这类写法——它把 Profile、Address、City 三个类的结构和关联方式“硬编码”在调用点,任一环节调整都会导致编译失败或空指针。
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 在 User 类中直接提供
getUserLocation(),内部协调 Profile 和 Address 的获取逻辑 - 若地址逻辑复杂或涉及远程服务,抽一个
LocationService统一提供能力,User 只依赖这个服务接口 - 调用方看到的是“获取用户所在地”,不是“怎么一层层扒对象”
配合接口抽象与依赖注入使用
仅靠 private 封装无法降低模块级耦合;必须让上层模块依赖下层的 接口,而不是具体实现类,并通过构造器或 setter 注入实例。
- 订单服务(OrderService)不 new AccountDaoImpl,而是接收一个
AccountDao接口参数 - 账户模块只需保证实现该接口,内部用 MyBatis、JPA 或 Mock 都不影响订单模块编译和运行
- Spring 启动时自动注入对应 Bean,切换实现只需改配置,不碰业务代码
把横切逻辑抽离成独立关注点
日志、权限、事务、审计等非核心业务逻辑,如果混在 Service 方法里,会让模块同时承担多个职责,被迫依赖 Logger、SecurityContext、TransactionManager 等一堆组件。
- 用 AOP 定义切面,比如
@LogExecutionTime注解自动记录耗时,不侵入业务方法体 - 用事件机制(ApplicationEventPublisher)触发通知,订单创建成功后发事件,由监听器处理短信、积分等后续动作
- 模块只专注“完成订单”这件事,不操心“谁来记日志”“谁来发消息”
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南










