PDF de programación - Ocultar la implementación - Piensa en Java

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ón de 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 progra-
mador 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 que eso des-
truirí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 programa-
dores clientes han usado? Esto también ocurre con aquellos métodos que sólo son parte de la im-
plementación de la clase, pero que no se diseñaron para ser usados directamente por el programa-
dor cliente. 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 crea-
dor de 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 pensar-
se que, al igual que el diseñador de la biblioteca, se deseará mantener "private" tanto como sea
posible, y exponer ú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 restric-
ciones. Para cuando acabe este capítulo, el lector debería convencerse del valor del control de
accesos en Java.

Sin embargo, el concepto de una 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 empa-
quetan 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 com-
pleta, 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 com-
pleto java.uti1. ArrayList (lo cual se puede hacer sin la sentencia import) o bien se puede simple-
mente decir ArrayList (gracias a la sentencia import).

Si se desea incorporar una única clase, es posible 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 cla-
ses 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éto-
do f( ) contenido en la clase A no colisionará con un método f( ) que tiene la misma lista de ar-
gumentos, dentro de la clase B. Pero, ¿qué ocurre con los nombres de clases? Supóngase que se
crea una clase Pila que se instala en una máquina que ya tiene una clase Pila escrita por otra per-
sona. Con Java en Internet, esto podría incluso ocurrir sin que el usuario lo sepa, dado que es po-
sible que algunas clases se descarguen automáticamente en el proceso de ejecutar un programa
Java.

Esta potencial colisión de nombres justifica la necesidad de tener control sobre los espacios de nom-
bre en Java, y de tener la capacidad de crear un nombre completamente único sin que importen las
limitaciones de Internet.

Hasta ahora, la mayoría de los ejemplos de este libro se incluían en un único fichero y están dise-
ñados para un uso local, por lo que no han tenido que hacer uso de los nombres de paquetes. (En
este caso el nombre de clase se ubica en el "paquete por defecto".) Ésta es ciertamente una opción,
y con motivo de mantener la máxima simplicidad, se usará este enfoque siempre que sea posible en
todo el resto del libro. Sin embargo, si se planifica crear bibliotecas o programas que se relacionan
con otros programas Java de la misma máquina, hay que pensar en evitar las colisiones entre nom-
bres de clases.

Cuando se crea un fichero de código fuente en Java, se crea lo que comúnmente se denomina una
unidad de compilación (en ocasiones se denomina una unidad de traducción). Cada una de estas
unidades tiene un nombre que acaba en .java, y dentro de la unidad de compilación puede haber
una única clase pública, sino, el compilador se quejará. El resto de clases de esa unidad de compi-
lación, si es que hay alguna, quedan ocultas para todo lo exterior al paquete al no ser pública, y
constituyen clases de "apoyo" para la clase pública principal.

5: Ocultar la implementación

171

Cuando se compila un fichero .java, se obtiene un fichero de salida que tiene exactamente el mis-
mo nombre pero tiene extensión .class por cada clase del fichero .java. Por tanto, se puede aca-
bar teniendo bastantes ficheros .class partiendo de un número pequeño de ficheros .java. Si se
programa haciendo uso de un lenguaje compilado, puede que uno esté acostumbrado a que el com-
pilador devuelva un fichero en un formato intermedio (generalmente un fichero "obj") que se em-
paqueta junto con otros de su misma clase utilizando, bien un montador (para crear un fichero eje-
cutable) o una biblioteca. Java no funciona así. Un programa en acción es un compendio de
ficheros .java, que pueden empaquetarse y comprimirse en un fichero JAR (utilizando la herra-
mienta jar de Java).

El intérprete de Java es el responsable de encontrar, cargar e interpretar estos ficheros1.

Una biblioteca también es un conjunto de estos ficheros de clase. Cada fichero tiene una clase que
es pública (no es obligatorio introducir una clase pública, pero lo habitual es hacerlo así), de for-
ma que hay un componente por cada fichero. Si se desea indicar que todos estos componentes (que
se encuentran en sus propios ficheros separados .java y .class) permanezcan unidos, es necesaria
la intervención de la palabra clave package.

Cuando se dice:

package mipaquete;

(al principio de un archivo), si se usa la sentencia package, ésta debe aparecer en la primera línea
que no sea un comentario del fichero), se está indicando que esa unidad de compilación es parte de
una biblioteca de nombre mipaquete. 0, dicho de otra forma, se está diciendo que el nombre de la
clase pública incluida en esa unidad de compilación se encuentra bajo el paraguas del nombre, mi-
paquete, y si alguien quiere utilizar el nombre, deben, o bien especificar completamente el nombre
o bien usar la palabra clave import en combinación con mipaquete (utilizando las opciones des-
critas previamente). Fíjese que la convención para los nombres de paquete de Java dice que se usen
únicamente letras minúsculas, incluso cuando hay más de una palabra.

Por ejemplo, supóngase que el nombre del fichero es MiClase.java. Esto significa que puede haber
una y sólo una clase pública en ese fichero, y el nombre de esa clase debe ser MiClase (incluidas
las mayúsculas y minúsculas):

package mipaquete;
public class MiClase {

/ / .

.

.



Ahora, si alguien desea usar MiClase o, por cualquier motivo, cualquiera de las clases públicas de
mipaquete, debe usar la palabra clave import para lograr que estén disponibles el/los nombres de
mipaquete. La alternativa es dar el nombre completo:

rnipaquete.MiClase m = new mipaquete.MiClase ( ) ;

' No hay nada en Java que obligue al uso de un intérprete. Existen compiladores de código nativo Java que generan un único fi-
chero ejecutable.

1

1

172

Piensa en Java

La palabra clave import puede lograr lo mismo pero de manera bastante más clara:

i m p o r t m i p a q u e t e
/ / .
M i C l a s e m = M i c l a s e ( ) ;

.

.



Merece la pena recordar que lo que las palabras clave package e import permiten hacer, como di-
señador de bibliotecas, es dividir el espacio de nombres único y global, de forma que no se tengan
colisiones de nombres, sin que importe cuánta gente se conecte a Internet y empiece a escribir cla-
ses en Java.

Creando nombres de paquete Únicos
Podría observarse que, dado que un paquete nunca se llega a "empaquetar" en un fichero único, un
mismo fichero podría estar constituidc por muchos ficheros .class, y esto podría ser fuente de de-
sorden y confusión. Para evitarlo, algo lógico es ubicar todos los ficheros .java de un paquete par-
ticular en un mismo directorio; es decir, hacer uso de la estructura de ficheros jerárquica del siste-
ma operativo y s