Tus clases ya modelan el dominio, protegen sus invariantes y exponen una API mínima. Y sin embargo, si imprimes un libro obtienes esto: com.nexussoftware.bibliotech.dominio.Libro@1b6d3586. Y si comparas dos ejemplares de "Java Efectivo" con el mismo ISBN, Java te dice que no son iguales. Ambos comportamientos vienen del mismo sitio: la clase Object, raíz de toda la jerarquía de Java, que proporciona implementaciones por defecto de una serie de métodos universales. Esas implementaciones funcionan, pero son deliberadamente conservadoras: toString no sabe qué es importante de tu clase y equals no sabe qué significa "igual" en tu dominio. Solo tú puedes decirlo. Esta lección te enseña a hacerlo bien, con el contrato completo de cada método, porque equals y hashCode mal escritos producen bugs que no se manifiestan hasta que tus objetos entran en una colección, y para entonces el fallo parece magia negra. Y al terminar, cerrarás el módulo cumpliendo la promesa que dejaste al final del módulo 2.

1. Object, la raíz de todo
2. Recorrido por los métodos de Object
3. toString: qué es ese @1b6d3586
4. Sobrescribir toString correctamente
5. equals: igualdad de referencia frente a igualdad lógica
6. El contrato de equals
7. Implementar equals paso a paso
8. El error clásico: equals(Libro) en vez de equals(Object)
9. hashCode: el contrato y por qué va siempre con equals
10. Implementar hashCode con Objects.hash
11. Qué se rompe si no sobrescribes hashCode
12. getClass() frente a instanceof en equals
13. Objects.equals y Objects.requireNonNull
14. Cierre del módulo: la refactorización final de BiblioTech
15. Errores Comunes y Consejos
16. Ejercicios

Como viste en 03-05, toda clase Java hereda de java.lang.Object, directa o indirectamente. Si no escribes extends, el compilador lo pone por ti.

Esto tiene dos consecuencias prácticas de las que ya te has beneficiado sin saberlo:

• Todo objeto tiene los métodos de Object. Puedes llamar a toString() sobre cualquier cosa.
• Object sirve como tipo común universal. Un parámetro Object acepta cualquier objeto, y por eso System.out.println(Object) funciona con lo que le eches. Es el polimorfismo de 03-06 llevado al límite.

Dos aclaraciones sobre las filas problemáticas:

clone() está desaconsejado. Su diseño obliga a implementar la interfaz marcadora Cloneable, produce copias superficiales por defecto y tiene una interacción confusa con final y la herencia. La alternativa es la que ya conoces: un constructor de copia.

finalize() no debe usarse jamás. Está marcado como obsoleto (deprecated) desde Java 9 y eliminado del uso práctico: no hay garantía de que se ejecute, ni de cuándo, ni siquiera de que se ejecute alguna vez. Para liberar recursos existe try-with-resources, que se estudia en la lección 06-06.

Cuando concatenas o imprimes un objeto, Java llama a su toString():

La implementación por defecto en Object es, literalmente:

Descompuesto:

Y aquí conviene deshacer un malentendido muy extendido: ese número no es la dirección de memoria. Es el valor devuelto por hashCode(), que en la implementación por defecto se deriva de la identidad del objeto, pero que la JVM puede calcular de varias formas y que no cambia aunque el recolector de basura mueva el objeto de sitio. Es un identificador, no una posición.

Como identificador funciona; como información, es inútil. Por eso toString se sobrescribe casi siempre.

Un buen toString es breve, informativo y sin efectos secundarios. Debe contener los datos que identifican al objeto para un humano.

Reglas prácticas:

Un toString útil para Prestamo, que delega en lo que ya sabe:

Ese cambio, por sí solo, mejora radicalmente la depuración: la ventana de variables del IDE y cualquier System.out.println pasan a mostrar información legible en vez de @1b6d3586.

Retomemos el == del módulo 1, ahora con objetos propios. Hay dos nociones de igualdad:

Con la implementación por defecto de Object, ambas son idénticas, porque Object.equals es exactamente esto:

De ahí el comportamiento que sorprende:

¿Es correcto? Depende de lo que signifique "igual" en BiblioTech. Y esa es una decisión de negocio, no técnica:

• Si Libro representa una obra bibliográfica, dos objetos con el mismo ISBN son el mismo libro. → hay que sobrescribir equals.
• Si Libro representa un ejemplar físico, dos ejemplares de la misma obra son cosas distintas aunque compartan ISBN. → la igualdad por identidad es correcta.

En BiblioTech adoptamos la primera interpretación: dos libros son iguales si tienen el mismo ISBN. Es la definición que usa el propio sector editorial, y encaja con nuestro vocabulario del dominio.

Recuerda además la lección del módulo 1 con String: "Java Efectivo" == otraCadena puede dar false aunque el texto sea idéntico, y por eso siempre comparabas con equals. Ahora ya sabes exactamente por qué: String sí sobrescribe equals para comparar el contenido.

equals no es un método cualquiera: tiene un contrato que toda la biblioteca estándar de Java asume que cumples. Si lo rompes, las colecciones del módulo 5 se comportarán de forma impredecible y la culpa no será suya.

Para referencias no nulas x, y, z:

La violación más frecuente en código real es la simetría, y suele aparecer así:

String.equals nunca considerará igual a un Libro, así que la relación no es simétrica y cualquier colección que dependa de ella fallará de forma aparentemente aleatoria.

Consejo derivado del contrato: compara solo con objetos de tu propio tipo.

La estructura canónica tiene cinco pasos, y conviene escribirla siempre igual:

Con el instanceof con patrón de Java 16 (lección 03-06), los pasos 2 y 3 se funden en uno:

Comprobación:

Fíjate en el caso a.equals(b): los títulos y años son distintos, pero el ISBN coincide, así que son el mismo libro. Eso es exactamente lo que decidimos en el apartado 5: la igualdad la define el dominio, no la coincidencia de todos los campos.

Sobre qué campos usar, tres criterios:

1. Solo campos significativos para la identidad. Un campo derivado o de estado transitorio (como disponible) no debe entrar.
2. Preferiblemente campos final. Si un campo usado en equals cambia, el objeto cambia de identidad, con las consecuencias del apartado 11.
3. Cuidado con los tipos: para float y double, usa Float.compare / Double.compare en lugar de ==, porque NaN != NaN rompería la reflexividad, y 0.0 y -0.0 son == pero se distinguen en el bit.

Este es el error que hay que ver una vez para no repetirlo nunca. Fíjate en la firma:

Compila sin ninguna queja. Y funciona... a veces:

El mismo par de objetos, dos resultados opuestos. ¿Por qué?

Porque equals(Libro) y equals(Object) tienen firmas distintas: son una sobrecarga, no una sobrescritura (tabla de 03-05). Y la sobrecarga se resuelve en compilación, según el tipo declarado (03-06). Con a y b declarados como Libro, el compilador elige tu método; con oa y ob declarados como Object, elige el de Object, que compara referencias.

Y lo peor es que todas las colecciones del módulo 5 llaman a equals(Object), porque internamente trabajan con referencias genéricas. Así que tu método nunca se usaría donde más falta hace, y el bug aparecería como "el HashSet tiene libros duplicados" sin ninguna pista sobre la causa.

La defensa es la anotación que ya conoces:

Un segundo escribiendo @Override frente a una tarde depurando. Esta es, probablemente, la razón más contundente de todas las que hemos dado para ponerla siempre.

hashCode() devuelve un entero que resume el contenido del objeto. Su uso está en las estructuras basadas en tablas hash —HashMap y HashSet, módulo 5—, que lo emplean para localizar objetos rápidamente sin comparar uno a uno.

Su contrato tiene tres cláusulas:

La cláusula 2 es la que impone la regla de oro:

Siempre que sobrescribas equals, sobrescribe hashCode. Sin excepciones.

La lógica es inevitable: si dos objetos son "iguales" pero producen códigos hash distintos, una tabla hash los colocará en cubos distintos y nunca los comparará entre sí, por lo que jamás descubrirá que son iguales.

Buena noticia: la cláusula 3 significa que un hashCode no tiene por qué ser único. Puede haber colisiones; la estructura las resuelve comparando con equals dentro del cubo. Un hashCode que devolviera siempre 0 sería correcto (cumple el contrato) pero inútil, porque degradaría el HashMap a una búsqueda lineal.

La forma moderna y recomendada es una línea, usando la clase utilitaria java.util.Objects:

Regla imprescindible: hashCode debe usar exactamente los mismos campos que equals. Si equals compara el ISBN, hashCode se calcula con el ISBN. Si añades un campo a uno, añádelo al otro. Es la causa número uno de incoherencias.

Con varios campos:

Objects.hash(...) es un varargs (03-03) que combina los códigos hash de sus argumentos con un algoritmo estándar. Internamente hace lo mismo que la fórmula clásica, que conviene conocer porque la verás en código antiguo y en entrevistas:

El 31 se usa porque es primo impar y porque 31 * x se optimiza a (x << 5) - x. No necesitas escribirlo a mano: Objects.hash es más legible y suficientemente bueno.

Una precaución de rendimiento: Objects.hash crea un array interno para los varargs, así que en clases con millones de instancias en bucles críticos puede notarse. Para todo lo demás —incluido BiblioTech—, es la opción correcta.

Este apartado justifica todo lo anterior. Supón que sobrescribes equals en Libro pero olvidas hashCode:

Son "iguales" y tienen códigos hash diferentes: la cláusula 2 está rota. Las consecuencias, que sufrirás en el módulo 5:

Un HashSet que admite duplicados. Un HashMap en el que guardas con una clave y no puedes recuperar con otra idéntica. Y ningún error, ninguna excepción, ninguna pista: simplemente, resultados incorrectos.

Ahí está la clave del diagrama: si el hashCode no coincide, equals ni siquiera se llega a llamar. Por eso el bug es tan desconcertante: tu equals es perfecto y aun así el resultado es incorrecto.

Regla final, en una frase: equals y hashCode se escriben juntos, se modifican juntos y se revisan juntos.

Existe una decisión de diseño en el paso 2 del equals, y merece conocerse porque tiene implicaciones reales con la herencia.

Variante con instanceof (la que hemos usado):

Variante con getClass():

La diferencia aparece con subclases. Imagina una LibroFirmado extends Libro:

El problema clásico de instanceof: si LibroFirmado sobrescribe equals añadiendo el firmante a la comparación, entonces libro.equals(libroFirmado) daría true (solo mira el ISBN) mientras que libroFirmado.equals(libro) daría false (además mira el firmante). Asimetría, y contrato roto.

Decisión para BiblioTech. Como Libro puede tener subclases y queremos simetría a prueba de todo, la implementación definitiva usará getClass(). Y la alternativa más limpia sigue siendo la de 03-07: declarar final la clase cuando no esté diseñada para ser extendida, con lo que el dilema desaparece.

Nota sobre record. Un record (lección 04-07) genera automáticamente equals, hashCode y toString a partir de todos sus componentes, con el contrato correctamente implementado. Es la mejor razón para usarlos en objetos de datos inmutables. Pero fíjate en el matiz: el equals generado usa todos los componentes, mientras que el nuestro usa solo el ISBN. Si tu noción de igualdad no es "todos los campos coinciden", el record no te sirve tal cual.

La clase java.util.Objects aporta dos utilidades que verás constantemente.

Objects.equals(a, b) compara dos referencias tratando null correctamente, sin que tengas que escribir la guarda:

Su implementación es exactamente (a == b) || (a != null && a.equals(b)). Úsala siempre dentro de equals cuando un campo pueda ser nulo.

Objects.requireNonNull(objeto, mensaje) verifica que una referencia no sea nula y falla inmediatamente si lo es. Su valor está en fallar pronto y con un mensaje claro, en el constructor, en lugar de dejar que un null viaje por el sistema y explote tres capas más allá:

Si alguien pasa null, el programa se detiene ahí mismo con:

Compáralo con el marcador "Material desconocido" que veníamos usando: aquel enmascaraba el error y permitía que el sistema siguiera con datos falsos. requireNonNull es la primera forma correcta de rechazar un argumento inválido que ves en el curso, y es un anticipo del módulo 6, donde aprenderás a lanzar excepciones deliberadamente. A partir de ahora, en las clases de dominio, es preferible a los avisos por consola.

Ha llegado el momento de cumplir la promesa que cerró el módulo 2. Recuerda el problema:

Los tres defectos que señalamos entonces: nada garantiza que las tres se actualicen juntas; el compilador no puede ayudar; y si mañana quieres añadir la multa o la referencia, hay que añadir una cuarta variable y otra línea que recordar.

Con lo aprendido en el módulo, las tres variables se convierten en una:

Una sola asignación. Es imposible dejar el estado a medias, porque no hay partes que actualizar por separado: o cambia el objeto entero, o no cambia nada. Y mostrarlo es una línea, gracias a toString:

Compara las dos versiones:

Las clases del dominio, con sus tres métodos de Object implementados:

Y un main que ya no calcula nada:

Salida:

Lo que sigue faltando, y ya sabes dónde se resuelve:

• Sobrescribir equals y olvidar hashCode. El error más caro de esta lección: no falla nada hasta que los objetos entran en un HashSet o un HashMap, y entonces falla en silencio.
• Escribir equals(MiClase) en vez de equals(Object). Sobrecarga en lugar de sobrescritura. @Override lo detecta al instante.
• Usar campos distintos en equals y hashCode. Rompe la cláusula 2 del contrato. Escríbelos siempre a la vez y con los mismos campos.
• Usar campos mutables en equals/hashCode. Si el campo cambia mientras el objeto está en una colección, el objeto se vuelve inencontrable dentro de ella. Usa campos final.
• Comparar double con == dentro de equals. NaN != NaN rompe la reflexividad. Usa Double.compare.
• Formatear datos con toString para procesarlos. Si otro código parsea tu toString, se convierte en una API que no podrás cambiar. Para eso hay métodos específicos.
• toString recursivo entre objetos que se referencian. StackOverflowError. Imprime el identificador del otro objeto, no el objeto entero.
• Consejo: deja que el IDE los genere. IntelliJ (Alt+Insert → equals() and hashCode()) y Eclipse (Alt+Shift+S) generan las tres implementaciones con el contrato correcto. Escríbelas a mano una vez para entenderlas, y después usa el generador.
• Consejo: si la clase es un contenedor de datos inmutable, plantéate un record (04-07): te da los tres métodos gratis y con el contrato bien implementado.
• Consejo: prueba el contrato. Cuatro assert o cuatro println comprobando reflexividad, simetría, transitividad y null cuestan un minuto y detectan el 90 % de los errores. En el módulo 11 lo harás con JUnit.

Implementa toString, equals y hashCode en Material y decide qué deben hacer las subclases:

1. En Material, la igualdad se define por referencia (el ISBN de un libro, el código de un DVD...).
2. Usa getClass() para garantizar la simetría, y comprueba con salida por consola que un Libro y un Dvd con la misma referencia no son iguales.
3. Sobrescribe toString en Material incluyendo tipo, título, referencia y disponibilidad, y compruébalo con las cuatro subclases.
4. Razona por escrito si Libro, Revista y Dvd necesitan sobrescribir equals y hashCode, o si les basta con heredarlos.

Escribe una clase de prueba que demuestre el error del apartado 8 en la misma ejecución:

1. Una clase LibroMal con public boolean equals(LibroMal otro) (sin @Override).
2. Dos objetos con el mismo ISBN.
3. Compáralos con referencias declaradas como LibroMal y con referencias declaradas como Object, imprimiendo los dos resultados.
4. Añade @Override y copia el mensaje exacto del compilador.
5. Corrige la firma y comprueba que ahora ambos resultados coinciden.

Escribe un método static boolean verificarContrato(Object x, Object y, Object z) que compruebe las cinco propiedades del contrato de equals sobre tres objetos e imprima un informe con el resultado de cada una, más la coherencia con hashCode. Pruébalo con:

1. Tres Libro correctos: dos con el mismo ISBN y uno distinto.
2. Una clase LibroSinHashCode que sobrescriba equals pero no hashCode, para ver qué comprobación falla.

Solución 1

Comprobación de la simetría entre tipos distintos:

Salida:

Observa un detalle elegante del toString de Material: usa getTipo(), que es polimórfico, así que cada subclase se identifica sola sin necesidad de sobrescribir toString. Es la lección 03-06 aplicada aquí.

4. ¿Deben las subclases sobrescribir equals y hashCode? No, y no deberían. Tres razones:

• La referencia ya identifica unívocamente cualquier material del catálogo: no hay dos libros con el mismo ISBN ni dos DVD con el mismo código. Añadir autor o duracionMinutos a la comparación no distinguiría nada nuevo.
• Sobrescribir equals en una subclase añadiendo campos es precisamente la fuente de asimetrías del apartado 12. Como Material.equals usa getClass(), un Libro y un Dvd ya nunca son iguales; el problema está resuelto en la clase base.
• Si necesitaran comparar más campos, hashCode tendría que actualizarse a la vez en cada subclase, multiplicando las oportunidades de error.

Regla que se deduce: define la igualdad una sola vez, en el nivel más alto de la jerarquía donde tenga sentido, y usa un campo identificador estable en lugar de la suma de todos los campos.

Solución 2

Salida:

Las trazas lo dejan clarísimo: en la versión incorrecta, la llamada a través de Object ni siquiera entra en tu método —no aparece el mensaje—, porque el compilador ha resuelto la llamada a Object.equals. En la correcta, tu método se ejecuta en ambos casos.

4. Mensaje del compilador al añadir @Override:

Cinco palabras que te habrían ahorrado el bug entero. En un HashSet (módulo 5), la versión incorrecta produciría duplicados sin ninguna señal de error.

Solución 3

Salida:

Lo revelador del caso 2: el equals es impecable —cumple las cinco propiedades— y aun así la clase está rota. Ese es exactamente el motivo de que el fallo sea tan difícil de encontrar en un proyecto real: todas las pruebas de igualdad pasan, y el sistema falla mucho más tarde, dentro de un HashMap, sin lanzar ninguna excepción.

Dos apuntes técnicos sobre el verificador. Primero, la comprobación de transitividad solo tiene sentido cuando el antecedente se cumple; si x e y no son iguales, la implicación es cierta por vacuidad y no hay nada que verificar. Segundo, este verificador es un anticipo de lo que harás en el módulo 11 con JUnit, donde estas comprobaciones se escriben como pruebas automáticas que se ejecutan en cada compilación en lugar de imprimir por consola.

Has cerrado el círculo. Sabes que Object es la raíz de toda la jerarquía y conoces sus métodos, incluidos los que no debes tocar (getClass), los desaconsejados (clone), los obsoletos (finalize) y los que esperan al módulo 8 (wait/notify). Entiendes qué es el críptico Libro@1b6d3586 —el nombre de la clase y el hashCode en hexadecimal, no una dirección de memoria— y sabes sustituirlo por un toString breve, informativo y sin efectos secundarios que transforma la depuración. Distingues la igualdad de referencia de la igualdad lógica, y sabes que decidir cuál aplica es una decisión del dominio: en BiblioTech, dos libros son el mismo libro si comparten ISBN. Dominas el contrato completo de equals —reflexivo, simétrico, transitivo, consistente y falso frente a null— y su implementación canónica en cinco pasos, con la variante moderna del instanceof con patrón. Has visto en ejecución el error clásico de escribir equals(Libro) en lugar de equals(Object), y por qué @Override es la diferencia entre un segundo y una tarde perdida. Conoces el contrato de hashCode, la regla inquebrantable de sobrescribirlo siempre junto a equals y con los mismos campos, Objects.hash para escribirlo en una línea, y exactamente qué se rompe si lo olvidas: un HashSet con duplicados y un equals al que nadie llega a llamar. Y añades a tu vocabulario Objects.equals y Objects.requireNonNull, la primera forma correcta de rechazar un argumento inválido que ves en el curso.

Con esto cierras el módulo 3, y BiblioTech es otro programa. Donde había veinte variables sueltas en un main de doscientas líneas, hay ahora ocho clases repartidas en tres paquetes: una jerarquía Material con tres soportes que aplican sus propias reglas por polimorfismo, un Empleado que hace cumplir su límite, un Prestamo que calcula su vencimiento al nacer y registra devoluciones completas en una sola llamada, una capa de presentación separada del dominio, y objetos que se imprimen y se comparan como es debido. Los campos son privados, las invariantes están garantizadas, la API pública está podada y añadir un soporte nuevo cuesta una clase y cero modificaciones. Y aquellas tres variables incómodas —mayorRetraso, empleadoMayorRetraso y libroMayorRetraso— son hoy un único objeto Prestamo coherente, tal como se prometió al terminar el módulo 2.

En el módulo 4, POO Avanzada, darás el salto de los mecanismos básicos a los que usan de verdad las bibliotecas profesionales de Java. Convertirás Material en una clase abstracta que no se pueda instanciar y que obligue a sus subclases a implementar lo que les toca; descubrirás las interfaces, con las que una clase puede comprometerse a varios contratos a la vez sin herencia múltiple; conocerás las clases internas y anónimas, las expresiones lambda y las referencias a métodos que cambian por completo la forma de escribir Java moderno; y terminarás con enumeraciones y records, que sustituirán esas cadenas "LEVE" y "GRAVE" por tipos seguros y generarán solos los tres métodos que acabas de escribir a mano. BiblioTech está listo para crecer.