与类访问修饰符相比，限制较少的成员访问修饰符有什么用？

假设我有一个包含一些成员的类，并且这些成员的限制访问修饰符比类本身少。

一个具体的例子可能是：

package apples;

class A { // package private
    public int foo() { // public (=> less restrictive than *package private*)
        return 42;
    }
}

据我了解，与成员访问修饰符相比，限制更严格的类访问修饰符将覆盖限制性较小的成员访问修饰符。因此，限制较少的成员访问修饰符应该完全无效。

我的理解正确吗？
- 如果没有，后果是什么？
限制成员访问修饰符较少的正当理由是什么？
最后，有什么最佳实践可遵循？

我也做了一些试验，因为我认为一旦开始传递函数引用，它可能会产生后果，但是即使那样，访问修饰符似乎也没有关系。

我构造的情况如下：

apples.B提供一个bla()返回对的引用的公共方法apples.A.foo。
然后pizzas.C调用apples.B.bla获取A.foo对它的引用并对其进行调用。
因此对A.foo()不能直接看到C，而只能通过间接访问B.bla()

我已经对其进行了测试，并且无论是否将foo() 包的访问修饰符设置为私有都不会有任何区别。

package apples;

import java.util.function.IntSupplier;

public class B {
    public IntSupplier getReferenceToAFoo() {
        A aInstance = new A();
        return aInstance::foo;
    }
}

package pizzas;

import apples.B;

import java.util.function.IntSupplier;

public class C {
    private int callAFooIndirectly() {
        B bInstance = new B();
        IntSupplier intsupplier = bInstance.getReferenceToAFoo();
        return intsupplier.getAsInt();
    }

    public static void main(String[] args) {
        C cInstance = new C();

        int i = cInstance.callAFooIndirectly();
        System.out.println(i);
        assert 42 == i;
    }
}

java oop access-modifiers

— 斯蒂芬·D
source

迄今为止，这种设计的最常见原因是使用非公共类提供公共API方法的实现（例如来自接口或扩展抽象类的方法）。JDK的本身就是充满了这样的类（例如：java.util.Collections.SingletonSet<E>是private的java.util.Collections）。

— ernest_k

我的理解正确吗？

是。

限制成员访问修饰符较少的正当理由是什么？

两个原因：

有时，您正在实现一个接口。接口方法必须是public
它使更改类的整体访问权限变得更加容易。例如，如果您标记了所有想要公开的方法public，即使是在包私有的类中，那么以后要使该类公开的所有工作就是添加public到类声明中。

最后，有什么最佳实践可遵循？

这只是一个见解，因此不适合堆栈溢出问题或答案。做您和/或您的团队认为合理的事情，和/或执行团队的风格指南告诉您的事情。

— TJ人群
source