Una de las preguntas más habituales en los exámenes de certificación es sobre Java package visibility , o dicho de otra forma, sobre la visibilidad que tienen nuestros métodos y variables para los diferentes packages. Para mucha gente en Java existen tres niveles de visibilidad.
Java Package Visibility (private vs public)
Estos dos ámbitos de visibilidad son los más conocidos , las variables publicas de una clase son accesibles desde cualquier otra clase , mientras las variables privadas son únicamente accesibles desde métodos de la misma clase.
Java Package Visibility (protected y default)
El ámbito de protected hace referencia a una variable o método que puede ser accedida desde la propia clase y desde las clases hijas.
Una pregunta muy habitual : ¿Es posible para una clase hija acceder a la variable protegida desde otro package?. La respuesta es SÍ. Acabamos de ver los tres ámbitos de visibilidad que se definen usando una palabra reservada. Ahora bien, existe un cuarto ámbito de visibilidad que no usa ninguna palabra reservada. Este ámbito se denomina ámbito de paquete (package) o default access.
En este caso la variable o método no tiene ninguna palabra reservada que asigne su visibilidad. Será accesible desde todas las clases que se encuentren en el mismo package. Las clases que pertenezcan a otro package no podrán acceder. Es la diferencia fundamental entre package visibility y public visibility.
Encapsulación y Visibilidad
Prácticamente todo el mundo entiende los ámbitos de visibilidad una vez que les explicas cada uno de ellos . Lo que a veces es más difícil de entender es cuando usar cada uno de ellos sobre todo el de package o default access. Vamos a construir un ejemplo que nos ayude.
package com.arquitecturajava.package1;
public class Servicio {
public String mensaje() {
return "hola";
}
}
package com.arquitecturajava.package1;
class ServicioUtilidad {
String mayusculas(String mensaje) {
return mensaje.toUpperCase();
}
}
Tenemos dos clases una tiene visibilidad pública que es lo más habitual , la segunda visibilidad de package. Es decir no lleva “public” en su declaración. ¿Por qué definir este clase así?. Porque suponemos que esta clase solo es útil para las clases que están dentro del package1 y fuera de él no tiene sentido que se vean. Estamos utilizando el concepto de encapsulación a nivel de packages.
Por lo tanto nuestro programa main solo mostrará la clase Servicio en el intellisense y no la de ServicioUtilidades ya que no podemos acceder a ella ,su visibilidad es de package.
Otros artículos relacionados:
Como dice David, yo preferiria poner todo privado y despues ir dando acceso a quien lo necesite, en este caso es publico.
El default o package, talvez no entre en una arquitectura de servicios como tal como suelen usarse en aplicaciones ABC, sino mas bien como modulos o paquetes de servicios, donde algo sea compartido para dicho modulo o paquete, pero no para servicios de paquetes ajenos,
Podrían encajar diseñando factorias públicas e implementaciones de servicios con visibilidad de packages
Supongo que en algunos contextos el uso de tantos ámbitos debe ser necesario. Yo trabajo con una aplicación bastante grande, en Spring MVC, y los ámbitos comunes son public y private. No pasamos de ahí, y supongo que debe de haber muy pocos usos del resto de ámbitos.
El artículo muy interesante. No conocía el default.
Gracias 🙂
Algo que puede parecer no muy evidente, es que las clases y miembros que se marcan como “protected” no sólo pueden ser accedidas por sub-clases, sino también por otras clases del mismo package (al igual que ocurre con el modificador por defecto, que no utiliza palabra reservada).
gracias