Al final de la lección anterior ocurrió algo que dejamos sin explicar. El método imprimirFicha(Material m) recibía indistintamente un Libro, una Revista o un Dvd, y cada uno respondía según lo que realmente era: el libro cobraba 0,25 € por día, el DVD 0,50 €, la revista 0,10 €. Y todo eso con una única línea de código de cálculo, escrita una sola vez en Material. Ese mecanismo se llama polimorfismo —del griego "muchas formas"— y es el pilar que justifica la existencia de la herencia. Sin él, una jerarquía de clases sería poco más que una forma de ahorrar líneas; con él, se convierte en la herramienta que permite añadir tipos nuevos sin modificar el código existente. Esta lección explica cómo funciona por dentro, cómo se usa bien, y por qué los if y switch sobre el tipo de un objeto —los que llenaban tu main en el módulo 2— son un síntoma de que falta polimorfismo.

1. Dos polimorfismos distintos
2. Tipo declarado frente a tipo real
3. El despacho dinámico paso a paso
4. El ejemplo central: Material que calcula multas
5. Upcasting: la conversión implícita
6. Downcasting y ClassCastException
7. instanceof y el patrón de Java 16
8. Los if sobre el tipo son un olor de diseño
9. Los miembros static no son polimórficos: hiding
10. Campos y polimorfismo: tampoco
11. Polimorfismo con arrays de la superclase
12. Errores Comunes y Consejos
13. Ejercicios

En Java conviven dos formas de polimorfismo que conviene no confundir:

El primero ya lo dominas: lo estudiaste en 03-03 y no tiene misterio, el compilador mira los tipos escritos y elige. El segundo es el interesante y el que da nombre al pilar de la POO; cuando alguien dice "polimorfismo" a secas, casi siempre se refiere a este.

Toda referencia en Java tiene dos tipos que pueden no coincidir:

Y de ahí salen las dos reglas que gobiernan todo lo demás:

El tipo declarado decide QUÉ PUEDES LLAMAR. El tipo real decide QUÉ SE EJECUTA.

Compruébalo:

El objeto es un DVD y tiene su campo duracionMinutos, pero el compilador solo ve un Material y Material no declara ese campo. La restricción no es caprichosa: el compilador debe garantizar que la llamada sea válida para cualquier objeto que pudiera estar ahí, y en esa variable podría haber un Libro.

El mecanismo por el que la JVM elige la implementación correcta se llama despacho dinámico (dynamic dispatch o late binding). Funciona así:

En dos frases: el compilador verifica que el método existe en el tipo declarado, y la JVM busca la implementación empezando por la clase real del objeto y subiendo por la jerarquía hasta encontrarla. Por eso Libro, que no sobrescribe getTarifaDiaria(), acaba ejecutando la de Material.

Este mecanismo tiene un coste mínimo en rendimiento (la JVM usa una tabla de métodos y además optimiza agresivamente en caliente), y a cambio da una flexibilidad enorme. En el módulo 10-07 verás cómo el compilador JIT llega incluso a eliminar ese coste cuando detecta que en la práctica siempre se ejecuta la misma implementación.

Este es el ejemplo que resume el módulo entero. Fíjate en calcularMulta, escrito una sola vez en Material:

Ese método no sabe —ni le importa— si el objeto es un libro, una revista o un DVD. Llama a getDiasPrestamo() y getTarifaDiaria(), y el despacho dinámico se encarga de que cada material aporte sus propios números.

Salida:

Verifícalo a mano: con 12 días transcurridos, el libro sigue en plazo (15 días); la revista lleva 5 de retraso (12 − 7) y paga 5 × 0,10 = 0,50 €, retraso leve porque 5 ≤ 7; el DVD lleva 9 de retraso (12 − 3) y paga 9 × 0,50 = 4,50 €, grave porque 9 > 7.

Tres líneas de código de negocio y tres comportamientos distintos. Y la propiedad más valiosa: si mañana Nexus Software añade mapas técnicos o kits de robótica, mostrar seguirá funcionando sin tocarse.

Asignar un objeto de una subclase a una referencia de la superclase se llama upcasting (conversión hacia arriba). Es implícito y siempre seguro, porque un Dvd siempre es un Material:

Qué cambia y qué no con el upcasting:

Es importante interiorizar que el upcasting no transforma nada: no crea un nuevo objeto ni recorta el original. Solo cambia las gafas con las que lo mira el compilador.

El downcasting es la operación inversa: tratar una referencia de la superclase como si fuera de la subclase. Requiere sintaxis explícita, porque no siempre es seguro:

Si el objeto real no es de ese tipo, el programa falla en ejecución:

El compilador acepta la conversión porque podría ser válida (un Material podría ser un Dvd), pero la comprobación real ocurre en ejecución. La ClassCastException se estudia como excepción en el módulo 6; aquí basta con saber que existe y cómo evitarla: comprobando el tipo antes con instanceof.

El operador instanceof responde a la pregunta "¿este objeto es de este tipo?":

Ese patrón —comprobar, castear, declarar variable— era tan repetitivo que Java 16 lo integró en el propio operador. Es el instanceof con patrón de tipo:

La variable dvd solo existe donde el compilador puede garantizar que la comprobación fue cierta, incluso en condiciones compuestas:

Dos detalles útiles:

• null instanceof Cualquiera devuelve false, nunca lanza error. Eso convierte a instanceof en una guarda de nulidad implícita.
• instanceof es cierto también para las superclases: dvd instanceof Material es true.

Ahora la parte importante de la lección. Compara estas dos formas de resolver el mismo problema.

Sin polimorfismo, tal como habrías tenido que escribirlo con lo que sabías en el módulo 2:

Con polimorfismo:

La comparación, punto por punto:

El criterio profesional, que conviene memorizar:

Si escribes un if o un switch que pregunta de qué tipo es un objeto para decidir qué hacer, casi siempre falta un método polimórfico.

Esto no significa que instanceof esté prohibido. Hay usos legítimos:

• Implementar equals (lección 03-09).
• Trabajar con APIs ajenas cuya jerarquía no puedes modificar.
• Recuperar un dato específico de un subtipo para presentarlo, como el duracionMinutos de un DVD en una ficha detallada, cuando ese dato no tiene equivalente en los demás.

El caso ilegítimo es el que sustituye a un comportamiento que debería vivir en las clases:

Aquí llega una trampa que hay que conocer para no caer en ella. Los métodos static no se sobrescriben: se ocultan (hiding), y se resuelven con el tipo declarado, no con el tipo real.

La primera línea es la sorprendente. El objeto es un Dvd, pero como descripcionTipo() es static, la JVM no hace despacho dinámico: usa el tipo declarado de m, que es Material. Es exactamente lo contrario de lo que hacen los métodos de instancia.

Contraste directo, en una tabla:

Prueba de fuego: si añades @Override al método static de Dvd, el compilador falla con "method does not override or implement a method from a supertype". Otra razón más para escribir siempre la anotación.

Consejo práctico: nunca llames a un método static a través de una referencia (m.descripcionTipo()). Escribe siempre Material.descripcionTipo() o Dvd.descripcionTipo(), y la ambigüedad desaparece del código.

La misma regla se aplica a los campos: los campos no son polimórficos, se resuelven con el tipo declarado.

El objeto contiene los dos campos a la vez, y cuál ves depende de con qué gafas lo mires. Es una fuente de errores tan absurda que la solución es sencilla: no declares en una subclase un campo con el mismo nombre que uno de la superclase. Y si lo que quieres es un valor que varíe por tipo, usa un método sobrescribible, como getTipo() en BiblioTech.

El polimorfismo brilla cuando tratas muchos objetos de forma uniforme. Para eso hace falta poder guardarlos juntos, y de momento la única herramienta disponible es un array:

Nota provisional. Los arrays tienen tamaño fijo y son incómodos para un catálogo real: no se puede añadir ni eliminar sin crear otro array. En el módulo 5 aparecerán ArrayList, HashMap y el resto del framework de colecciones, que es la solución definitiva. Usa el array aquí como andamio para ver el polimorfismo en acción.

Salida:

Un array de Material puede contener objetos de cualquier subclase, y el bucle los trata a todos por igual mientras cada uno hace lo suyo. Este es, en esencia, el motivo por el que existe la POO en el software grande.

Un detalle a tener en cuenta: al recorrer el array, el tipo declarado de m es Material, así que solo puedes llamar a lo que Material declare. Si necesitas el autor de los libros, harás falta instanceof con patrón:

Y este es exactamente uno de los usos legítimos del apartado 8: extraer un dato que solo existe en un subtipo, no decidir comportamiento de negocio.

• Creer que el upcasting "convierte" el objeto. No lo toca. Solo limita lo que el compilador te deja llamar. El objeto sigue siendo lo que era, y sus métodos sobrescritos siguen ejecutándose.
• Hacer downcasting sin comprobar. (Dvd) m sin un instanceof delante es una ClassCastException esperando su momento. Usa siempre if (m instanceof Dvd dvd).
• Poner @Override a un método static. No compila, y esa es su virtud: te avisa de que no estás sobrescribiendo, sino ocultando.
• Llamar a métodos static a través de una instancia. m.descripcionTipo() engaña sobre qué se va a ejecutar. Usa el nombre de la clase.
• Redefinir un campo en la subclase. Acabas con dos campos con el mismo nombre en el mismo objeto y resultados que dependen del tipo declarado. No lo hagas.
• Cadenas de else if (x instanceof ...). Casi siempre significan que falta un método en la jerarquía. Antes de escribir la tercera rama, pregúntate qué método debería tener Material.
• Consejo: cuando añadas una subclase, prueba a listar qué métodos sobrescribe. Si no sobrescribe ninguno, quizá no necesitabas una subclase, sino un campo.
• Consejo: programa contra el tipo más general que te sirva. Declara Material m en lugar de Dvd d cuando no necesites lo específico del DVD: tu código valdrá para más casos. Este principio se lleva al extremo en el módulo 4 con las interfaces.
• Consejo: usa la marca del margen del IDE. IntelliJ y Eclipse muestran un icono junto a los métodos sobrescritos y permiten saltar a la implementación real con un clic.

Este ejercicio comprueba la propiedad más valiosa del polimorfismo. Nexus Software incorpora kits de robótica al catálogo: se prestan 5 días, con tarifa de 1,00 €/día (son caros), y tienen un campo numeroPiezas.

1. Crea KitRobotica como subclase de Material.
2. Añádelo al array catalogo del apartado 11.
3. Ejecuta sin modificar ni una línea de Material, Libro, Revista, Dvd, mostrar ni el bucle de listado.
4. Verifica manualmente la multa a 12 días transcurridos y la gravedad.

Después responde: ¿cuántos ficheros has tenido que tocar? ¿Cuántos habrías tocado con el switch del apartado 8?

Un compañero ha escrito este método en BiblioTechApp. Refactorízalo eliminando por completo el switch, moviendo cada responsabilidad a la clase que le corresponde. Indica qué métodos nuevos necesita Material y cuáles sobrescribe cada subclase.

Escribe una clase de prueba que demuestre en la misma ejecución las tres reglas del apartado 9 y 10:

1. Un método de instancia sobrescrito ejecuta la versión del tipo real.
2. Un método static redefinido ejecuta la versión del tipo declarado.
3. Un campo redefinido se lee según el tipo declarado, aunque el objeto sea el mismo.

Imprime en cada caso el tipo declarado, el tipo real (con getClass().getSimpleName()) y el valor obtenido, y explica por escrito por qué el resultado 1 difiere de los resultados 2 y 3.

Solución 1

Solo hay que añadirlo al array:

Salida (fila nueva marcada):

Verificación manual, prestando atención a la frontera: 12 − 5 = 7 días de retraso; 7 × 1,00 = 7,00 €, por debajo del tope de 20 €. Y la gravedad es LEVE, no GRAVE, porque la condición es retraso <= UMBRAL_LEVE y UMBRAL_LEVE vale exactamente 7. Es justo el tipo de valor límite que la lección 02-05 te enseñó a comprobar: los umbrales se prueban siempre con los tres valores frontera (6, 7 y 8), porque un < en lugar de un <= cambiaría este resultado sin que ninguna otra fila de la tabla se enterase.

Respuesta a la pregunta. Has tocado dos ficheros: uno nuevo (KitRobotica.java) y una línea en BiblioTechApp para darlo de alta. Con el switch del apartado 8 habrías tenido que localizar y modificar todos los métodos que contuvieran un switch sobre el tipo —cálculo de multa, listado, avisos, validación—, con el riesgo de olvidar alguno y que el kit acabara tratado como un libro sin que nadie se enterara.

Solución 2

El switch decide dos cosas —el canal de aviso y los días de preaviso— que son propiedades de cada soporte. Su sitio son las clases.

En Material, dos métodos nuevos con el valor por defecto, y un tercero que compone el mensaje una sola vez:

En Revista:

En Dvd:

Libro no sobrescribe nada: hereda "correo" y 3 días, que eran justamente el caso default del switch original. Y BiblioTechApp se queda sin el método:

Resultados:

Tres ganancias concretas: el default silencioso desaparece, cada soporte reúne todas sus reglas en su fichero, y añadir un tipo nuevo ya no obliga a recorrer el código buscando switch olvidados.

Solución 3

Salida:

Explicación. La línea b == d da true: hay un solo objeto y dos referencias, así que cualquier diferencia entre las tres salidas viene del tipo declarado, no del objeto.

El caso 1 usa despacho dinámico: los métodos de instancia se resuelven en ejecución mirando la clase real, que es Derivada en ambos casos. Es el único de los tres que es polimórfico.

Los casos 2 y 3 se resuelven en compilación. El compilador sustituye b.metodoStatic() por Base.metodoStatic() y b.campo por el campo declarado en Base, porque ese es el tipo con el que se declaró la variable. La JVM ni siquiera llega a preguntarse qué objeto hay detrás. Por eso el mismo objeto exhibe dos valores distintos para campo: el objeto contiene ambos campos, y cada referencia lee el suyo.

La moraleja práctica de los tres casos juntos: el polimorfismo es cosa exclusiva de los métodos de instancia. Cualquier otro mecanismo —static, campos— se resuelve por el tipo escrito y produce sorpresas si intentas usarlo como si fuera polimórfico.

Has llegado al núcleo de la orientación a objetos. Distingues los dos polimorfismos —la sobrecarga, que resuelve el compilador, y la sobrescritura, que resuelve la JVM— y comprendes la regla que los gobierna: el tipo declarado decide qué puedes llamar, el tipo real decide qué se ejecuta. Has seguido el despacho dinámico paso a paso y has visto su consecuencia práctica en el ejemplo central del módulo: un único calcularMulta en Material que cobra 0,25 € a un libro, 0,10 € a una revista y 0,50 € a un DVD, sin un solo if sobre el tipo. Dominas el upcasting implícito y seguro, el downcasting explícito y arriesgado con su ClassCastException, y la forma moderna de protegerte con instanceof y patrón de tipo (if (m instanceof Dvd dvd)), que en una línea comprueba, convierte y declara. Sabes reconocer los if/switch sobre el tipo como un olor de diseño y refactorizarlos moviendo cada regla a la clase que le corresponde. Y conoces las dos excepciones que hay que tener siempre presentes: los métodos static no se sobrescriben, se ocultan, y los campos tampoco son polimórficos; ambos se resuelven por el tipo declarado.

Sobre todo, has comprobado en la práctica la propiedad que justifica todo el andamiaje: añadir un kit de robótica al catálogo ha costado una clase nueva y una línea, sin tocar nada de lo que ya funcionaba.

Queda una debilidad grave en el diseño actual, y la habrás notado: todos los campos siguen siendo public. Cualquiera puede escribir libro.disponible = true saltándose los avisos de prestar(), y nada impide asignar a un préstamo una multa inventada. En la lección siguiente, Encapsulamiento, cerrarás esa puerta: harás privados los campos de Libro, Empleado y Prestamo, aprenderás la tabla completa de modificadores de acceso, verás por qué poner un setter a cada campo destruye precisamente lo que se pretendía proteger, y descubrirás la inmutabilidad y las copias defensivas como herramientas para que el estado de tus objetos sea, de verdad, suyo.