java包机制与访问修饰符协同实现权限控制：包是物理边界，修饰符是逻辑规则；按业务分包（如model、service），结合public（对外契约）、protected（子类扩展）、默认（包内协作）、private（严格封装）实现清晰安全的访问控制。

Java 中包机制和访问修饰符配合使用，才能真正实现清晰、安全、可维护的权限控制。关键不是单独记修饰符含义，而是理解“包”作为物理边界、“修饰符”作为逻辑规则，二者共同决定谁能访问什么。

按功能分包，是权限控制的前提

包不是目录别名，而是访问控制的容器。规范做法是按业务或职责划分包名，例如：

• 实体类统一放在 com.example.model 或 com.example.entity
• 服务逻辑放在 com.example.service，接口与实现可进一步细分（如 .service 和 .service.impl）
• 控制器放在 com.example.controller，只暴露必要 public 方法
• 工具类放在 com.example.util，内部辅助方法用默认（包私有）修饰即可

这样设计后，包结构本身就成了天然的访问层级——不同包之间默认隔开，为后续用 protected 或默认权限留出合理空间。

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

四种修饰符的真实作用场景

修饰符的意义必须结合包关系来理解：

• public：仅用于对外契约。比如 Service 接口方法、Controller 的处理方法、工具类的静态入口。不要给实体字段或内部逻辑方法加 public
• protected：适用于基类中“允许子类扩展但不开放给任意调用者”的成员。例如 BaseEntity 中的 prePersist()，同包内其他类能调，跨包子类也能重写或调用，但不能通过 new 父类实例去访问
• 默认（无修饰符）：最常被低估的权限。适合包内协作成员，比如 service.impl 包里多个实现类共用的模板方法、model 包内 IdGenerator 类供同包实体调用的生成逻辑
• private：所有字段优先设为 private；构造器、getter/setter、内部工具方法也应 private，除非明确需要被继承或外部调用

实体类封装的典型写法

以用户实体为例，体现包与修饰符协同：

• 包路径：com.example.user.model.User
• 字段全用 private，避免外部直接读写
• 提供 public getter/setter，但 setter 中加入校验（如邮箱格式、密码长度）
• 若需同包内高效构造（如 DAO 层映射），可加一个 package-private 构造器：User(String name, String email)（不写修饰符），仅限 model 包内使用
• 敏感操作如 changePassword() 设为 private 或 default，由 public 的 updateProfile() 统一调度

避免常见误用

这些做法看似方便，实则破坏封装和可维护性：

• 把所有类扔进默认包（无 package 声明）——失去包级访问控制能力
• 在 service 层返回 public 字段的实体，导致调用方绕过业务逻辑直接改状态
• 为图省事把工具方法设为 public static，结果被其他模块随意调用，形成隐式依赖
• 子类中用 new 父类().protectedMethod()——编译报错，因为 protected 不允许跨实例访问，只能调用 this.protectedMethod() 或继承后重写

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南