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

Question

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

一个具体的例子可以是：

package apples;

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

据我理解，类访问修饰符比成员访问修饰符限制性更强，它将覆盖限制较小的成员访问修饰符。因此，限制较少的成员访问修饰符应该没有任何效果。

我的理解是正确的吗?如果不是，consequences?是什么？

​

modifiers?

• Finally，的成员访问限制较少的有效理由是什么？

可以遵循哪些最佳实践？

我还做了一些实验，因为我认为当我开始传递函数引用时，它可能会产生后果，但是即使这样，访问修饰符似乎也不重要。

我所设想的情况如下：

• apples.B提供了一个公共方法bla()，它返回对apples.A.foo.
• Then pizzas.C的引用，调用apples.B.bla来获取对A.foo的引用并调用它。

我对它进行了测试，无论我是否将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;
    }
}

Answer 1

我的理解是对的吗？

是。

使用限制较少的成员访问修饰符的有效理由是什么？

原因有二：

有时，您正在实现一个接口；接口方法必须是public

• It，这样可以更容易地更改类的总体访问权限。例如，如果您标记了所有希望成为公共public的方法，即使是在包私有类中，那么以后您所要做的就是向类public添加public。

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

这是一个意见问题，所以不太适合堆叠溢出的问题或答案。做你和/或你的团队认为合理的事情，和/或做你的团队风格指南让你做的事情。