Bruce_Eckel_Piensa_en_Java 05 capítulo

5: Ocultar la
Una consideración primordial del diseño orientado a objetos es "la separación de
aquellas cosas que varían de aquéllas que permanecen constantes".
Esto es especialmente importante en el caso de las bibliotecas. El usuario (el programador cliente)
de la biblioteca debe ser capaz de confiar en la parte que usa, y saber que no necesita reescribir el
código si se lanza una nueva versiónde esa biblioteca. Por otro lado, el creador de la biblioteca debe
tener la libertad para hacer modificaciones y mejoras con la certeza de que el código del programador cliente no se verá afectado por estos cambios.
Esto puede lograse mediante una convención. Por ejemplo, el programador de la biblioteca debe
acordar no eliminar métodos existentes al modificar una clase de la biblioteca, dado queeso destruiría el código del programador cliente. El caso contrario sería más problemático. En el caso de
un atributo ¿cómo puede el creador de la biblioteca saber qué atributos son los que los programadores clientes han usado? Esto también ocurre con aquellos métodos que sólo son parte de la implementación de la clase, pero que no se diseñaron para ser usados directamente por el programadorcliente. Pero, ¿qué ocurre si el creador de la biblioteca desea desechar una implementación
antigua y poner una nueva? El cambio de cualquiera de esos miembros podría romper el código de
un programador cliente. Por consiguiente, el creador de la biblioteca se encuentra limitado, y no

puede cambiar nada.
Para solucionar este problema, Java proporciona especificadores de acceso para permitir al creadorde la biblioteca decir qué está disponible para el programador cliente, y qué no. Los niveles
de control de acceso desde el "acceso máximo" hasta el "acceso mínimo" son public, protected,
"friendly" (para el que no existe palabra clave), y private. Por el párrafo anterior podría pensarse que, al igual que el diseñador de la biblioteca, se deseará mantener "private" tanto como sea
posible, yexponer únicamente los métodos que se desee que use el programador cliente. Esto
es completamente correcto, incluso aunque frecuentemente no es intuitivo para aquéllos que
programan en otros lenguajes (especialmente C), y se utilizan para acceder a todo sin restricciones. Para cuando acabe este capítulo, el lector debería convencerse del valor del control de
accesos en Java.
Sin embargo, el concepto deuna biblioteca de componentes y el control sobre quién puede acceder
a los componentes de esa biblioteca están completos. Todavía queda la cuestión de cómo se empaquetan los componentes para formar una unidad cohesiva. Esto se controla en Java con la palabra
clave package, y los especificadores de acceso se ven en la medida en que una clase se encuentre
en un mismo o distinto paquete. Por tanto,para empezar este capítulo, se aprenderá cómo ubicar
los componentes de las bibliotecas en paquetes. Posteriormente, uno será capaz de comprender el
significado completo de los especificadores de acceso.

170

Piensa en Java

El paquete: la uh-¡dad de biblioteca
Un paquete es lo que se obtiene al utilizar la palabra clave import para importar una biblioteca completa, como en:
import java.uti1. *;Esto trae la biblioteca de utilidades entera, que es parte de la distribución estándar de Java. Dado
que, por ejemplo, la clase ArrayList se encuentra en java.uti1 es posible especificar el nombre completo java.uti1. ArrayList (lo cual se puede hacer sin la sentencia import) o bien se puede simplemente decir ArrayList (gracias a la sentencia import).

Si se desea incorporar una única clase, esposible nombrarla sin la sentencia import:
import java.util.ArrayList;

Ahora es posible hacer uso de ArrayList, aunque no estarán disponibles ninguna de las otras clases de java-util.

La razón de todas estas importaciones es proporcionar un mecanismo para gestionar los "espacios
de nombres". Los nombres de todas las clases miembros están aislados unos de otros. Un método f( ) contenido en la...