En la lección anterior dibujaste el plano: tres clases, Libro, Empleado y Prestamo, con sus atributos y sus responsabilidades. Ahora toca construir. Esta lección es la que convierte el diagrama en código Java real: aprenderás la sintaxis exacta para declarar una clase, qué valor tienen sus campos antes de que nadie los asigne, cómo crear objetos con new y qué ocurre exactamente en la memoria cuando lo haces. Verás por qué null no es "vacío" sino "ninguna dirección", qué significa realmente el NullPointerException que tarde o temprano te va a saltar, y una de las sorpresas más desagradables para quien empieza: dos variables pueden apuntar al mismo objeto, de modo que modificarlo por una lo modifica también para la otra. Al terminar, "Java Efectivo", "Patrones de Diseño" y "Refactorización" existirán en tu programa como tres objetos con vida propia.

1. Declarar una clase: sintaxis mínima
2. Campos de instancia y valores por defecto
3. Un fichero por clase pública y organización en paquetes
4. Crear objetos con new
5. Qué ocurre en memoria: pila y heap
6. Acceder a los campos con el punto
7. La referencia null y el NullPointerException
8. Aliasing: varias referencias al mismo objeto
9. Campos static frente a campos de instancia
10. Constantes static final
11. Ciclo de vida de un objeto y recolección de basura
12. BiblioTech: primera versión de Libro en funcionamiento
13. Errores Comunes y Consejos
14. Ejercicios

Una clase es, en su forma más simple, un nombre y un bloque:

Diseccionémoslo con la misma calma con la que en el módulo 1 diseccionaste main:

• public es un modificador de acceso: indica que la clase es visible desde cualquier paquete. Si lo omites, la clase solo será visible dentro de su propio paquete (visibilidad default, o "de paquete"). Los modificadores se estudian a fondo en la lección 03-07.
• class es la palabra reservada que declara una clase.
• Libro es el nombre. Por convención (módulo 1): sustantivo, singular, en UpperCamelCase.
• Las llaves delimitan el cuerpo de la clase, donde viven campos, constructores y métodos.

Ojo a una diferencia fundamental respecto a todo lo que has escrito hasta ahora: dentro del cuerpo de una clase no puedes poner sentencias sueltas. Esto no compila:

El cuerpo de una clase solo admite declaraciones: campos, constructores, métodos, bloques de inicialización y otras clases. El código ejecutable vive dentro de métodos.

Un campo (o atributo, o variable de instancia) se declara igual que una variable local, pero directamente en el cuerpo de la clase:

Nota importante: estos campos son public solo de forma provisional, para que puedas manipularlos con el punto mientras aprendes el mecanismo. En la lección 03-07 los harás private y los expondrás mediante operaciones controladas, que es como se escribe código profesional. Considera este public un andamio.

Y aquí llega la primera diferencia importante con las variables locales que ya conoces. En el módulo 1 aprendiste que una variable local debe inicializarse antes de usarse o el compilador se queja. Los campos, en cambio, se inicializan automáticamente con un valor por defecto:

Esa inicialización automática es una comodidad, pero también una trampa: un objeto recién creado con new Libro() es un libro sin título, sin autor y no disponible, es decir, un objeto en estado inválido. La solución definitiva son los constructores, que estudiarás en la lección 03-04 y que garantizan que ningún objeto nazca incompleto. Por ahora, asignaremos los campos a mano.

Reglas del lenguaje, no de estilo:

• Un fichero .java puede contener como máximo una clase public.
• Si contiene una clase public, el fichero debe llamarse igual que la clase, con la misma capitalización: Libro va en Libro.java.
• El package declarado en la primera línea debe corresponder con la ruta de directorios (módulo 1).

Aplicado al proyecto bibliotech, la estructura queda así:

El subpaquete dominio no es un capricho: separa las clases que representan el negocio del código que ejecuta la aplicación. Es la primera decisión de arquitectura del curso, y la retomarás en 03-07 (encapsulamiento a nivel de paquete) y en el módulo 12.

Como BiblioTechApp y Libro están ahora en paquetes distintos, tu clase de arranque necesita un import:

Es exactamente el mismo mecanismo que usabas con import java.util.Scanner;. La diferencia es que ahora la clase importada la has escrito tú.

La clase es el plano; new es la constructora que levanta la casa:

Tres partes que conviene separar mentalmente:

Los paréntesis de new Libro() son una llamada al constructor. Como todavía no has escrito ninguno, Java te proporciona un constructor por defecto sin parámetros que no hace nada más que crear el objeto. En 03-04 verás cuándo desaparece ese regalo.

Nada te obliga a guardar la referencia:

Ese objeto existe durante un instante y queda inalcanzable: no hay ninguna variable que lleve a él, así que el recolector de basura acabará eliminándolo (apartado 11).

Recupera del módulo 1 la distinción entre pila (stack) y montículo (heap):

• La pila guarda las variables locales y los parámetros de cada método en ejecución. Es pequeña, rapidísima y se libera sola al terminar el método.
• El heap guarda todos los objetos. Es grande, lo gestiona la JVM y lo limpia el recolector de basura.

Ejecuta mentalmente este fragmento:

Cuatro lecturas que debes extraer del diagrama:

1. La variable no contiene el objeto, contiene una flecha hacia él. Las direcciones (0x1A) son ficticias; nunca las verás ni las necesitas.
2. Cada new produce un objeto distinto, aunque los valores fueran idénticos.
3. Los campos viven dentro del objeto, en el heap, no en la pila.
4. Cuando main termine, a y b desaparecen de la pila; los objetos del heap quedan sin referencias y se convierten en basura.

El operador . sirve para llegar al interior de un objeto a través de una referencia:

El punto se lee como un genitivo: javaEfectivo.titulo es "el título de javaEfectivo". Y se puede encadenar cuando un campo es a su vez un objeto:

Funciona, pero anota mentalmente que encadenar puntos es un olor de diseño llamado tren de mensajes; la lección 03-07 lo formaliza con la Ley de Demeter.

Los campos también se pueden usar en cualquier expresión de las que ya dominas:

null es un valor especial que significa "esta referencia no apunta a ningún objeto". No es cero, no es cadena vacía, no es un objeto "en blanco": es la ausencia de dirección.

Imprimir una referencia nula es inofensivo. Lo que no es inofensivo es intentar usar el punto sobre ella:

El programa se detiene con una traza como esta:

Léela con el método sistemático de la lección 02-05:

Ese "because ... is null" es una mejora enorme de Java moderno: en versiones antiguas solo veías el nombre de la excepción y la línea, y con a.b.c.d había que adivinar cuál de los cuatro era nulo.

Un NullPointerException no se resuelve con try/catch (módulo 6): se resuelve evitando que exista la referencia nula. Las herramientas para ello son las guardas de nulidad que ya usaste en el módulo 2 y, sobre todo, los constructores que obligan a dar valores (03-04):

Recuerda del módulo 1 la regla de comparar cadenas: con un posible null de por medio, "Java Efectivo".equals(libro.titulo) es más seguro que libro.titulo.equals("Java Efectivo"), porque el literal nunca es nulo.

Este es el concepto que más sorpresas causa. Observa:

Libro copia = original; no duplica el objeto. Copia la referencia, es decir, la dirección. El resultado son dos variables apuntando al mismo objeto del heap:

A este fenómeno se le llama aliasing (dos nombres para la misma cosa). Consecuencias prácticas:

Comprueba la diferencia entre mutar y reapuntar:

Y compara la identidad con la igualdad, retomando el == del módulo 1:

Dos libros con el mismo ISBN son objetos diferentes y == lo dice claramente. ¿Y si quieres que se consideren iguales por su ISBN? Eso exige sobrescribir equals, y es el tema de la lección 03-09.

Si de verdad quieres duplicar un objeto, hay que hacerlo campo a campo (o con un constructor de copia, lección 03-04):

Todos los campos vistos hasta ahora son de instancia: cada objeto tiene su propia copia. Un campo static es distinto: pertenece a la clase, y existe una sola copia compartida por todos los objetos.

El caso de uso clásico es un contador. Nexus Software quiere saber cuántos préstamos se han creado durante la sesión:

De momento el contador hay que incrementarlo a mano al crear cada préstamo (en 03-04 lo hará el constructor, que es su sitio natural):

Diferencias esenciales:

Java permite acceder a un campo static a través de una instancia (p1.prestamosCreados), pero es muy mala práctica: da la falsa impresión de que el valor pertenece a ese objeto. Usa siempre el nombre de la clase.

Y una advertencia: los campos static mutables son estado global disfrazado, con los mismos riesgos que las veinte variables de main. Úsalos para contadores, constantes y poco más.

Combinando static (una sola copia) con final (no se puede reasignar, módulo 1) se obtiene la forma canónica de declarar una constante:

Esto resuelve un problema real de tu código actual: hasta ahora las cuatro reglas de negocio eran final locales dentro de main, invisibles para cualquier otra parte del programa. Ahora viven en la clase que las gobierna y se usan desde cualquier sitio:

Convenciones para constantes (módulo 1): MAYUSCULAS_CON_GUION_BAJO. Y una precaución: final impide reasignar la variable, no modificar el objeto al que apunta. public static final Libro CATALOGO_BASE = new Libro(); te impediría hacer CATALOGO_BASE = otroLibro;, pero no CATALOGO_BASE.titulo = "Otro";. Por eso las constantes se declaran de tipos inmutables (primitivos, String).

Un objeto Java atraviesa tres fases:

En Java no existe un operador para destruir objetos (no hay delete como en C++). Cuando un objeto deja de ser alcanzable desde cualquier referencia viva, se convierte en candidato a ser eliminado por el recolector de basura (garbage collector, GC), un proceso de la JVM que libera memoria automáticamente.

Tres cosas que debes saber ya, sin entrar en detalles:

• No controlas cuándo se ejecuta el GC. Puede ser inmediatamente o mucho después. System.gc() es una sugerencia que la JVM puede ignorar; no lo uses.
• El GC elimina la mayor parte de las fugas de memoria, pero no todas: si mantienes referencias vivas a objetos que ya no necesitas (por ejemplo, en una estructura global que crece sin límite), la memoria no se libera.
• No pongas lógica de limpieza en finalize(): está obsoleto desde Java 9 y no debe usarse (lección 03-09).

El funcionamiento interno del GC, las generaciones y el ajuste de rendimiento se estudian en la lección 10-07.

Reunamos todo. Fichero src/main/java/com/nexussoftware/bibliotech/dominio/Libro.java:

Fichero Prestamo.java, todavía mínimo (sus operaciones llegan en 03-03 y su constructor en 03-04):

Y el arranque, BiblioTechApp.java:

Salida:

Compara este código con el del módulo 2. Los datos de un libro ya no están dispersos: viajan juntos dentro de un objeto, y puedes pasar el libro entero a un método con un solo parámetro (imprimir(javaEfectivo)) en lugar de cinco. Y p.libro = refactorizacion; es aliasing intencionado: el préstamo apunta al mismo ejemplar del catálogo, así que cuando en la próxima lección marques p.libro.disponible = false, el catálogo se enterará solo.

Lo que todavía falta salta a la vista: los objetos nacen vacíos y hay que rellenarlos a mano campo a campo (constructores, 03-04), no saben hacer nada (métodos, 03-03), y con más de tres libros el código se vuelve inviable porque no hay dónde guardarlos: eso lo resuelve el módulo 5 con las colecciones.

• Olvidar el new. Libro libro; declara una referencia, no crea nada. Si la usas, obtienes un NullPointerException (si es campo) o un error de compilación por variable no inicializada (si es local).
• Creer que = copia el objeto. Es el error del apartado 8. b = a; crea un alias, no una copia. Si necesitas un objeto independiente, hay que construirlo.
• Confundir null con "" o con 0. null significa "sin objeto". Una cadena vacía es un objeto String perfectamente válido, sobre el que puedes llamar métodos; sobre null no puedes llamar nada.
• Poner el nombre del fichero distinto al de la clase pública. class Libro en libro.java no compila en sistemas sensibles a mayúsculas (todos los Linux, y la JVM en general). Deja que el IDE cree las clases por ti.
• Declarar campos como static "porque así se accede más fácil". Es la vía rápida a un estado global compartido por todos los objetos: si titulo fuese static, ¡los tres libros tendrían el mismo título! Un campo es static solo si su valor es genuinamente común a toda la clase.
• Acceder a un campo static mediante una instancia. p1.prestamosCreados compila, pero engaña al lector. Escribe siempre Prestamo.prestamosCreados.
• Consejo: ante un NullPointerException, no busques dónde falló, busca dónde faltó asignar. El mensaje "because X is null" te da el nombre exacto de la referencia; retrocede hasta el punto donde debería haberse asignado.
• Consejo: acostúmbrate ya a Alt+Insert / "Generate" del IDE. Generará constructores, getters y toString en cuanto los estudies. Pero escríbelos a mano las primeras veces: solo así entiendes qué genera.

Crea la clase Empleado en el paquete com.nexussoftware.bibliotech.dominio con:

• Campos públicos nombre (String), identificador (String) y prestamosAcumulados (int).
• Un campo static empleadosRegistrados que cuente cuántos se han creado.
• Una constante static final MAX_PRESTAMOS_SIMULTANEOS con valor 3.

Después, en BiblioTechApp, crea los tres empleados de Nexus Software (Marta Ruiz con identificador EMP-001, Diego Alonso con EMP-002 y Nuria Vidal con EMP-003), asígnales 2, 0 y 4 préstamos acumulados respectivamente, imprime una tabla con printf y señala con un asterisco a quienes superen el máximo permitido. Muestra al final el contador de empleados registrados.

Escribe un programa que demuestre, con salida por consola, las cuatro situaciones de la tabla del apartado 8, usando dos referencias Libro:

1. Mutar el objeto a través de una referencia y ver el cambio desde la otra.
2. Reapuntar una referencia a un objeto nuevo y comprobar que la otra no cambia.
3. Comparar con == dos referencias al mismo objeto y dos objetos distintos con idéntico ISBN.
4. Poner una referencia a null y comprobar que el objeto sigue accesible desde la otra.

Explica en comentarios qué ocurre en memoria en cada paso.

Escribe un fragmento que provoque deliberadamente un NullPointerException sobre un objeto Prestamo cuyo campo libro no se ha asignado. Copia la traza completa que obtienes, identifica en ella la referencia nula, la línea culpable y el campo al que se intentaba acceder. Después, corrige el programa sin usar try/catch, de dos maneras distintas: (a) con una guarda de nulidad, y (b) asignando el campo antes de usarlo. Razona cuál de las dos es mejor solución y por qué.

Solución 1

Empleado.java:

Uso en BiblioTechApp:

Salida:

Puntos clave: MAX_PRESTAMOS_SIMULTANEOS es static final porque la política es de la empresa, no de cada persona; empleadosRegistrados es static (uno para todos) mientras que prestamosAcumulados es de instancia (uno por empleado). Si confundieras ambos, los tres empleados compartirían el mismo número de préstamos, que es justamente el error del apartado de consejos.

Solución 2

Salida:

La regla que hay que memorizar: el punto muta el objeto y se ve desde todos los alias; el = mueve la flecha de una sola variable.

Solución 3

Código que provoca el fallo:

Traza obtenida:

Lectura de la traza:

(a) Guarda de nulidad, con el patrón del módulo 2:

(b) Asignar el campo antes de usarlo:

¿Cuál es mejor? La (b), sin ninguna duda. La opción (a) trata el síntoma: acepta que puedan existir préstamos sin libro y añade una comprobación que habría que repetir en cada punto donde se use p.libro. La opción (b) ataca la causa: un préstamo sin libro no es un préstamo, es un objeto en estado inválido que nunca debió existir.

La versión definitiva de esa idea llega en la lección 03-04: un constructor que exija el libro como parámetro hace que sea imposible crear un Prestamo incompleto, y entonces la guarda de nulidad sobra porque el caso no puede darse. Esa es la diferencia entre programar defensivamente y diseñar bien: el mejor NullPointerException es el que no puede ocurrir.

Has dado el salto de dibujar clases a escribirlas. Sabes declarar una clase y sus campos, y conoces la regla —a menudo olvidada— de que los campos se inicializan solos con 0, false o null, lo que hace que un objeto recién creado pueda estar perfectamente vacío y perfectamente inválido. Has visto qué hace exactamente new: reservar memoria en el heap, inicializar los campos y devolver una referencia que guardas en la pila; y has trazado ese reparto de memoria en diagramas. Manejas el operador punto para leer y escribir campos, entiendes null como ausencia de dirección y sabes leer un NullPointerException hasta identificar qué referencia falló y por qué. Has comprendido el aliasing, que es el origen de una parte enorme de los errores de quien empieza: b = a no copia, comparte. Distingues campos de instancia de campos static, has llevado las cuatro reglas de negocio de BiblioTech a constantes static final dentro de Prestamo, donde por fin están en su sitio, y sabes que la memoria la libera el recolector de basura sin que tú intervengas. Tu catálogo ya son objetos: Libro, Empleado y un Prestamo que los relaciona.

Pero tus objetos todavía no saben hacer nada: son cajas de datos que alguien manipula desde fuera. Falta la mitad viva de la POO. En la lección siguiente, Métodos, darás comportamiento a tus clases: aprenderás la anatomía completa de un método, descubrirás por qué en Java todo se pasa por valor —y qué implica eso, sorprendentemente, cuando el argumento es un objeto—, dominarás la sobrecarga, this, los varargs y la diferencia entre métodos static y de instancia. Y harás la primera gran refactorización del módulo: sacar de main los cálculos de días de retraso, multa y gravedad, y mudarlos a Prestamo, que es su dueño legítimo.