访问修饰符是落实高内聚低耦合的关键守门人：private封装内部细节，package-private强化包内协作，protected仅用于明确继承场景，public接口须聚焦业务契约、避免实现泄漏。
访问修饰符本身不直接实现高内聚低耦合，但它是落实这两项原则的关键“守门人”。用对了，能天然约束职责边界、隔离变化源头；用错了，比如滥用 public 或暴露 protected 字段，会迅速瓦解内聚、拉高耦合。
只暴露必要接口，用 private 封装内部细节
类的字段和辅助方法默认应为 private。这不是为了“防人”，而是明确告诉调用方：“这些不是你该关心的”。比如一个 Order 实体类，订单总金额不应是可直接修改的字段：
- ❌ 错误：
public BigDecimal totalAmount;—— 外部可随意赋值，绕过价格计算逻辑 - ✅ 正确：
private BigDecimal totalAmount;，仅通过calculateTotal()计算并由构造器或 builder 设置
所有 getter/setter 也要审慎：若某个字段不该被外部修改（如主键 id），就只提供 getter；若集合字段需防篡改，返回不可变副本：return Collections.unmodifiableList(orders);
用 package-private（默认）强化包内协作，弱化跨包依赖
当多个类属于同一业务包（如 com.example.order），且某些逻辑只应在包内复用时，不加修饰符（即 package-private）是最自然的选择。它比 protected 更安全，又比 private 更灵活：
立即学习“Java免费学习笔记（深入）”；
- 包内工具类（如
OrderValidator）的方法可设为 package-private，供OrderService和OrderController直接调用，无需暴露给其他模块 - 避免把本该包内的校验逻辑硬塞进
public接口，导致其他包误用或产生隐式依赖
这种设计让包成为真正的“内聚单元”——包外看不到、也不需要知道这些协作细节。
protected 谨慎使用：只留给明确的继承扩展场景
protected 是个信号灯：它表示“我允许子类介入我的内部，但仅限于继承关系”。滥用它会快速破坏内聚：
- ❌ 不要只为“方便测试”把字段设为
protected；测试应通过 public 行为验证，而非直接读写状态 - ✅ 可用于模板方法模式中的钩子方法，如
protected void beforeSave() { }，但必须有明确的“is-a”继承语义（如RefundOrder是Order的一种） - 若发现多个不相关的类都想访问某个
protected方法，说明它本该是public接口的一部分，或应抽成独立策略
public 接口聚焦契约，拒绝实现泄漏
一个类对外的 public 成员，就是它向世界承诺的全部能力。每增加一个 public 方法或字段，都意味着承担长期兼容责任：
- public 方法名应体现业务意图（如
confirmPayment()），而非技术动作（如updateStatusToPaid()） - 返回类型避免具体实现（如不返回
ArrayList<order></order>），优先用接口（List<order></order>）或 DTO - 不要因“以后可能用到”而提前暴露方法；YAGNI 原则在此同样适用——真正需要时再加，比清理废弃 public API 容易得多
