封装通过隐藏变化细节、暴露稳定接口实现代码复用：UserUtils等工具类提供公共静态方法供多模块调用；Order类用私有字段+getter/setter保障数据安全与结构统一；PaymentService等封装业务行为如refund()提升自然复用；构造器与Builder模式统一复杂对象初始化逻辑。
封装直接支撑代码复用，不是靠“多写几遍”，而是靠“一次写好、多处安心用”。关键在于把变化的细节藏起来，把稳定的接口亮出来。
封装让类变成可插拔的模块
一个封装良好的类，比如 UserUtils 工具类，内部可能封装了手机号格式校验、密码强度检测、用户名脱敏等逻辑。这些方法都设为 public static，外部只需导入这个类，就能在登录模块、注册模块、后台管理模块中反复调用，无需复制粘贴校验代码，也不用关心正则怎么写、加密用什么算法。
- 同一套校验逻辑，在不同业务场景下被调用几十次，但只维护一处
- 后续升级密码规则（如要求必须含特殊字符），改 UserUtils.checkPassword() 一个地方，全系统生效
私有字段 + 公共 getter/setter 构成复用基础
以 Order 类为例：订单号、创建时间、状态等字段声明为 private，再提供标准的 getOrderId()、setOrderStatus() 方法。这样，订单查询服务、支付回调服务、物流同步服务都能安全地读写订单数据，而不会因直接操作字段引发空指针或状态错乱。
- 多个服务共享同一个类定义，避免各自定义“看似一样实则不兼容”的 Order 结构
- 如果某天需要对订单号加解密，只需修改 getOrderId() 内部实现，所有调用方无感
封装业务行为，复用更自然
真正提升复用性的，不只是“能读能写”，而是“能做事”。比如 PaymentService 类不只暴露 amount 字段，而是封装 refund(double fee)、confirmPaid() 等方法。这些方法内部自动处理状态校验、金额扣减、日志记录、事务回滚等通用逻辑。
立即学习“Java免费学习笔记（深入）”；
- 退款功能在电商前台、客服后台、对账系统中都被调用，但每处只需一行 payment.refund(199.0)
- 新增“部分退款”需求？扩展 refund(double fee, boolean partial) 即可，旧调用不受影响
结合构造器与 builder 模式，复用初始化逻辑
复杂对象（如 HTTP 请求配置、数据库连接参数）常通过封装的构造器或静态 builder 方法创建。例如 HttpRequest.builder().url("...").timeout(5000).header("Auth", token).build()，把零散参数组装逻辑收束在一个地方。
- 各业务模块不用重复写 new HttpRequest(...) + 一堆 setXXX()，减少出错点
- 后续统一增加默认超时、自动重试策略，只需改 builder 的 build() 实现
