¿Cuál es el uso de modificadores de acceso miembro menos restrictivas que el modificador de acceso de clase?

Stefan D.:

Decir que tengo una clase con algunos de los miembros, y los miembros tienen un modificador de acceso menos restrictiva que la propia clase.

Un ejemplo concreto podría ser:

package apples;

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

A mi entender una clase de modificador de acceso que es más restrictivo que el miembro de modificador de acceso , anulará las menos restrictivas miembro de modificadores de acceso . Por lo que una menos restrictiva miembro de modificador de acceso no debe tener ningún efecto en absoluto.

• ¿Es correcta mi entendimiento?
  • Si no es así, ¿cuáles son las consecuencias?
• Lo que podría haber razones válidas para tener modificadores de acceso miembro menos restrictivas?
• Por último, ¿qué hay mejor práctica a seguir?

---

También hice un poco de experimentación porque pensé que podría tener consecuencias una vez que comience pasando referencias de las funciones alrededor, sin embargo, incluso entonces el modificador de acceso no parece importar.

La situación que he construido es la siguiente:

• apples.Bproporciona un método público bla()que devuelve una referencia a apples.A.foo.
• A continuación, pizzas.Clas llamadas apples.B.blapara obtener una referencia a A.fooy lo llama.
• Así que A.foo()no es directamente visible para C, pero es sólo indirectamente accesible a travésB.bla()

Lo he comprobado y no hace una diferencia si hago el modificador de acceso de foo() paquete privado o no.

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;
    }
}

TJ Crowder:

¿Es correcta mi entendimiento?

Si.

Lo que podría haber razones válidas para tener modificadores de acceso miembro menos restrictivas?

Dos razones:

• A veces, está implementando una interfaz; métodos de interfaz deben serpublic
• Esto hace que sea más fácil para cambiar el acceso general de su clase. Por ejemplo, si marca todos los métodos que alguna vez había desea ser pública public, incluso en una clase de paquete-privada, luego todo lo que tiene que hacer para que el público de clase es adicionado publica la declaración de clase.

Por último, ¿cuáles son las mejores prácticas que hay que seguir?

Eso es una cuestión de opinión, por lo que no se adapta bien a una pregunta de desbordamiento de pila o respuesta. Haz lo que parece razonable para usted y / o su grupo, y / o hacer lo guía de estilo de su equipo dice que hagas.