同包不同类调用时访问修饰符如何影响方法可见性？

Question

在Java中，当同一个包内的不同类尝试调用彼此的方法时，访问修饰符如何影响方法的可见性？例如，类A在package1中定义了一个默认（包私有）方法methodA()，类B也在package1中，能否直接调用methodA()？若将methodA()改为private、protected或public，可见性会发生怎样的变化？特别是protected修饰符，在同包不同类的场景下是否比默认访问更具优势？开发者常误认为protected仅限于继承关系使用，而忽略其在包内可见性的特性。请解释四种访问修饰符在此场景下的实际行为差异及常见误区。

Answer 1

一、Java访问修饰符基础概念与同包可见性概述

在Java中，类成员（字段、方法、构造器等）的可见性由四种访问修饰符控制：private、默认（包私有）、protected和public。这些修饰符不仅影响继承关系中的可见性，也深刻影响同一包内不同类之间的访问能力。

当多个类位于同一个包中时，它们天然具备一定的“信任”关系，Java语言规范允许包内类之间共享某些非公开成员。理解这种机制对于构建模块化、低耦合但高内聚的系统至关重要。

二、四种访问修饰符在同包场景下的行为对比

访问修饰符	本类可访问	同包其他类可访问	子类可访问（不同包）	全局可访问
private	✓	✗	✗	✗
默认（包私有）	✓	✓	✗	✗
protected	✓	✓	✓（通过继承）	✗
public	✓	✓	✓	✓

三、具体案例分析：类A与类B在package1中的调用行为

假设我们有如下结构：

package package1;

class A {
    void methodDefault() { }
    private void methodPrivate() { }
    protected void methodProtected() { }
    public void methodPublic() { }
}

class B {
    void testAccess() {
        A a = new A();
        a.methodDefault();     // ✅ 允许：同包访问默认方法
        // a.methodPrivate(); // ❌ 编译错误：私有方法不可见
        a.methodProtected();   // ✅ 允许：protected在同包中可见
        a.methodPublic();      // ✅ 允许：公有方法全局可见
    }
}

四、深入解析：protected在同包环境中的双重优势

许多开发者误以为protected仅用于继承场景，即“只有子类才能访问”。然而，根据JLS（Java Language Specification），protected成员具有两个维度的可见性：

• 同一包内的任何类均可直接访问
• 不同包中的子类可通过继承访问（即使不能直接实例化调用）

这意味着，在同包情况下，protected的可见性范围等于或大于默认访问级别。例如：

class C extends A {
    void testInherited() {
        methodProtected(); // ✅ 通过继承访问
        methodDefault();   // ✅ 同包+继承，也可访问
    }
}

若将methodDefault()移至另一个包的子类，则无法访问，而methodProtected()仍可被继承使用。

五、常见误区与开发实践建议

以下是开发者常犯的认知偏差：

1. 误区一：“protected只能被子类访问” —— 实际上它在同包中对所有类开放。
2. 误区二：“默认访问比protected更安全” —— 在同包中两者等效，但在跨包继承时protected更具扩展性。
3. 误区三：“只要不暴露public就没问题” —— 忽视了包内过度耦合的风险。

因此，在设计API时应权衡：若预期未来会被跨包子类复用，优先使用protected而非默认访问。

六、可视化流程图：方法调用权限决策路径

graph TD A[开始: 类B尝试调用类A的方法] --> B{方法是private吗?} B -- 是 --> C[拒绝访问] B -- 否 --> D{在同一个包内吗?} D -- 否 --> E{是子类且方法为protected吗?} D -- 是 --> F[允许访问: 包内可见] E -- 是 --> G[允许访问: 继承可见] E -- 否 --> H{方法是public吗?} H -- 是 --> I[允许访问] H -- 否 --> J[拒绝访问]

七、性能与设计权衡：访问控制与系统架构的关系

虽然访问修饰符不影响运行时性能（均由编译器检查），但其选择直接影响代码的可维护性和演化成本。例如：

• 使用默认访问可限制外部包依赖，增强封装性
• protected为框架设计提供灵活性，适合SPI（服务提供接口）模式
• 滥用public会导致API膨胀，增加兼容性负担
• private应作为默认起点，仅在必要时放宽

现代Java模块系统（JPMS）进一步强化了包级别的访问控制，使得默认和protected的行为在模块边界更加严格。

八、高级话题：模块化时代下的访问控制演进

自Java 9引入模块系统后，即使同包也不再绝对保证可见性。例如：

// module-info.java
module com.example.core {
    exports package1; // 只有导出的包才对外可见
}

此时，即便方法是public，若所在包未被exports，其他模块依然无法访问。这标志着从“包为中心”向“模块为中心”的访问控制范式迁移。

九、测试验证：编写单元测试确认可见性规则

推荐通过编写的编译时测试来验证理解是否正确：

@Test
void testPackageAccess() {
    A a = new A();
    // assertDoesNotThrow(() -> a.methodPublic());
    // assertDoesNotThrow(() -> a.methodProtected());
    // assertDoesNotThrow(() -> a.methodDefault());
    // assertThrows(CompilationException.class, () -> a.methodPrivate());
}

此类测试虽不能直接运行，但可通过注释说明预期行为，辅助团队知识传递。