封装需与包协同设计，按业务域划分包并内聚类，善用默认访问权限，控制类粒度与构造方式以保障安全性。
封装不只是把字段设成 private 再加 get/set 方法，它真正落地时，必须和包（package）协同设计。类是封装的最小单元，包是封装的组织边界——两者配合得当，才能让代码既安全又易维护。
按业务职责划分包，而不是按技术类型
常见误区是建一堆“util”“entity”“dao”包，结果所有模块都往里塞，最后变成一锅粥。合理做法是先识别核心业务域，再为每个域建独立包：
- 用户相关功能 → com.example.app.user
- 订单流程逻辑 → com.example.app.order
- 支付网关适配 → com.example.app.payment
每个包内部自包含：实体类、服务接口、实现类、异常类型。这样外部模块只能通过明确的 public 接口调用，无法绕过业务规则直接操作底层数据。
包内访问权限要主动利用，默认（package-private）不是摆设
Java 的默认访问级别（不写任何修饰符）表示“仅本包可见”，这是封装中被严重低估的工具：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 把只供本包内协作使用的辅助类、工具方法、内部状态枚举设为默认访问，不暴露给其他包
- 比如 order 包里有个
OrderValidator类，只被本包的 service 使用，就不要声明为 public - 这样既能复用逻辑，又避免了外部误用或强依赖内部实现细节
类的封装粒度要匹配包的语义边界
一个包不该塞几十个类，也不该只有孤零零一个类。理想情况是：
- 每个包聚焦解决一个明确问题，含 3–12 个紧密协作的类
- 对外只提供少量 public 类作为入口（如
UserService、OrderProcessor） - 其余类用 default 或 private（嵌套类）隐藏，形成“黑盒”结构
例如在 user 包中：UserRepository 可以是 public（供其他包注入），但它的 JDBC 实现类 JdbcUserRepositoryImpl 应设为 package-private，甚至不对外导出具体实现类名。
避免跨包直接访问成员变量或构造敏感对象
即使用了 private 字段，如果包设计松散，仍可能引发封装失效：
- 禁止不同业务包之间通过 new 创建对方的实体类（如
new Order()），应统一由工厂或 builder 构造 - 实体类的构造器尽量私有或 protected，强制走 builder 或静态工厂方法（如
Order.createFromCart(...)） - 敏感字段（如密码、token）在 setter 中做校验和脱敏，且绝不允许通过反射绕过——这需要包级约束配合代码审查机制
