java - una - métodos públicos en clases privadas de paquete
llamar variable de otra clase java (7)
¿Hace la diferencia marcar los métodos como public en clases de paquete privado?
class SomePackagePrivateClass
{
void foo(); // package private method
public void bar(); // public method
}
¿Hay alguna diferencia práctica en la visibilidad entre foo y bar aquí?
Bueno ... tuve esta duda también (es por eso que busqué este hilo). Esta podría ser una buena pregunta.
Pero ...
Después de pensarlo dos veces, las cosas son más simples de lo que pensamos.
Un método privado de paquete es un método privado de paquete.
Parece tonterías? Pero ...
Un método privado de paquete, incluso si su clase se hereda, sigue siendo un método privado de paquete.
¿Tiene más sentido ahora? Para una explicación más detallada:
Un método privado de paquete, incluso si su clase es heredada por una subclase más visible, sigue siendo un método privado de paquete.
Si la subclase es del mismo paquete, esos métodos privados del paquete también se heredan, pero todavía son privados del paquete .
Si la subclase es del paquete diferente (de aquí, necesitamos que la clase padre sea pública, con algunos métodos privados del paquete), esos métodos privados del paquete no se heredan (porque no son visibles en absoluto).
Un punto a tener en cuenta, que puede ser la causa de esta duda, que un método privado de paquete en una clase pública no es visible fuera de su paquete también.
Lo anterior explica sobre el método privado del paquete. Y el caso del método público es el mismo.
Cuando una clase privada de paquete es heredada por una subclase pública (del mismo paquete, esto es obligatorio), sus métodos públicos se heredan como métodos públicos y, por lo tanto, se convierten en métodos públicos en una clase pública.
En el ejemplo OP, como foo() y bar() están ambos en una clase privada de paquete, sus visibilidades están limitadas a paquete privado en este momento, hasta que se agreguen más códigos (por ejemplo, herencia).
Espero que esto sea lo suficientemente claro (y simple).
Ejemplo usando herencia:
A.java
package pkg1
class A {
void foo();
public void bar() {};
}
B.java
package pkg1
public class B extends A{
}
C.java
package pkg2
public class C {
public void doSomething() {
B b = new B();
b.bar(); //ok
b.foo(); //won''t work, since foo() is not visible outside of package ''pkg1''
A a = new A(); //won''t work since A is not visible outside of package ''pkg1''
a.bar(); //won''t work, since a cannot be created
}
}
Hace muy poca diferencia, a menos que la clase sea extendida por una clase pública (o anidada protegida).
Como una cuestión de coherencia, iría por lo public . Debería ser raro que los métodos no sean public o private .
Hay una serie de ejemplos de métodos públicos en el paquete privado de la clase java.lang.AbstractStringBuilder . Por ejemplo, length() es pública en AbstractStringBuilder y se expone en la clase pública StringBuilder (anulada en StringBuffer para agregar sincronización).
Otro caso donde el método tiene que ser público es cuando está creando un paquete de implementación privada de alguna clase pública o interfaz. Como no tiene permitido reducir la visibilidad de los métodos anulados, estos deben ser públicos.
Sí. public métodos public en una clase paquete privado pueden ser útiles. Ejemplo ilustrativo de la biblioteca de Java (y tomado del clásico "java efectivo"):
¿Alguna vez has visto java.util.JumboEnumSet, java.util.RegularEnumSet ?? Probablemente no, porque son privados y no se mencionan en la documentación.
¿Alguna vez los has usado? Probablemente si. Se devuelven mediante el método estático de java.util.EnumSet.noneOf(...) . Aunque no puede construirlos usted mismo, puede usar sus métodos públicos cuando se devuelven desde este método.
Lo bueno de eso es que no sabes cuál estás usando o incluso si existen. Java decide cuál es más eficiente dependiendo de los argumentos, y puede usar un diferente en una versión más nueva. Usted solo accede a su funcionalidad al referirse a ellos a través de su interfaz común (¡lo cual es una buena práctica de todos modos!)
Si la clase no va a ser ampliada por otra subclase más visible *, la única diferencia es la claridad de intención . La declaración privada de todos los paquetes de métodos hace que sea más difícil para los lectores futuros determinar cuáles de los métodos deben llamar otras clases en el mismo paquete.
* que no tendría mucho sentido como una solución de diseño para mí, pero técnicamente es posible sin embargo.
foo tiene default package visibility donde la bar tiene visibilidad public