8.6 Polimorfismo

El polimorfismo es otro de los grandes pilares sobre los que se sustenta la Programación Orientada a Objetos (junto con la encapsulación y la herencia). Se trata nuevamente de otra forma más de establecer diferencias entre interfaz e implementación, es decir, entre el qué y el cómo.

La encapsulación te ha permitido agrupar características (atributos) y comportamientos (métodos) dentro de una misma unidad (clase), pudiendo darles un mayor o menor componente de visibilidad, y permitiendo separar al máximo posible la interfaz de la implementación.

Por otro lado la herencia te ha proporcionado la posibilidad de tratar a los objetos como pertenecientes a una jerarquía de clases. Esta capacidad va a ser fundamental a la hora de poder manipular muchos posibles objetos de clases diferentes como si fueran de la misma clase (polimorfismo).

El polimorfismo te va a permitir mejorar la organización y la legibilidad del código así como la posibilidad de desarrollar aplicaciones que sean más fáciles de ampliar a la hora de incorporar nuevas funcionalidades. Si la implementación y la utilización de las clases es lo suficientemente genérica y extensible será más sencillo poder volver a este código para incluir nuevos requerimientos.

1. Concepto de polimorfismo

El polimorfismo consiste en la capacidad de poder utilizar una referencia a un objeto de una determinada clase como si fuera de otra clase (en concreto una subclase). Es una manera de decir que una clase podría tener varias (poli) formas (morfismo).

Un método "polimórfico" ofrece la posibilidad de ser distinguido (saber a qué clase pertenece) en tiempo de ejecución en lugar de en tiempo de compilación. Para poder hacer algo así es necesario utilizar métodos que pertenecen a una superclase y que en cada subclase se implementan de una forma en particular. En tiempo de compilación se invocará al método sin saber exactamente si será el de una subclase u otra (pues se está invocando al de la superclase). Sólo en tiempo de ejecución (una vez instanciada una u otra subclase) se conocerá realmente qué método (de qué subclase) es el que finalmente va a ser invocado.

Esta forma de trabajar te va a permitir hasta cierto punto "desentenderte" del tipo de objeto específico (subclase) para centrarte en el tipo de objeto genérico (superclase). De este modo podrás manipular objetos hasta cierto punto "desconocidos" en tiempo de compilación y que sólo durante la ejecución del programa se sabrá exactamente de qué tipo de objeto (subclase) se trata.

A tener en cuenta

El polimorfismo ofrece la posibilidad de que toda referencia a un objeto de una superclase pueda tomar la forma de una referencia a un objeto de una de sus subclases. Esto te va a permitir escribir programas que procesen objetos de clases que formen parte de la misma jerarquía como si todos fueran objetos de sus superclases.

A tener en cuenta

El polimorfismo puede llevarse a cabo tanto con superclases (abstractas o no) como con interfaces.

Ejemplo 6.01: polimorfismo

Dada una superclase ClaseX, con un método m, y dos subclases ClaseA y ClaseB, que redefinen ese método m, podrías declarar un objeto objetoX de tipo ClaseX que durante la ejecución podrá ser de tipo ClaseA o de tipo ClaseB (algo desconocido en tiempo de compilación). Esto significa que al invocarse el método m de ClaseX (superclase), se estará en realidad invocando al método m de ClaseA o de ClaseB (alguna de sus subclases). Por ejemplo:

// Declaración de una referencia a un objeto de ClaseX
ClaseX objetoX; // Objeto de tipo X (superclase)
...

// Zona del programa donde se instancia un objeto de ClaseA (subclase) y se le asigna a la referencia objetoX.
// La variable obj adquiere la forma de la subclase ClaseA.
objetoX = new ClaseA();
...

// Otra zona del programa.
// Aquí se instancia un objeto de ClaseB (subclase) y se le asigna a la referencia objetoX.
// La variable obj adquiere la forma de la subclase ClaseB.
objetoX = new ClaseB();
...

// Zona donde se utiliza el método m sin saber realmente qué subclase se está utilizando.
// (Sólo se sabrá durante la ejecución del programa)

objetoX.m()
// Llamada al método m (sin saber si será el método m de ClaseA o de ClaseB).
...

Imagina que estás trabajando con las clases Alumno y Profesor y que en determinada zona del código podrías tener objetos, tanto de un tipo como de otro, pero eso sólo se sabrá según vaya discurriendo la ejecución del programa. En algunos casos, es posible que un determinado objeto pudiera ser de la clase Alumno y en otros de la clase Profesor, pero en cualquier caso serán objetos de la clase Persona. Eso significa que la llamada a un método de la clase Persona (por ejemplo devolverContenidoString) en realidad será en unos casos a un método (con el mismo nombre) de la clase Alumno y, en otros, a un método (con el mismo nombre también) de la clase Profesor. Esto será posible hacerlo gracias a la ligadura dinámica.

2. Ligadura dinámica

La conexión que tiene lugar durante una llamada a un método suele ser llamada ligadura (conexión o vinculación que tiene lugar durante una llamada a un método para saber qué código debe ser ejecutado. Puede ser estática o dinámica, vinculación o enlace (en inglés binding).

Si esta vinculación se lleva a cabo durante el proceso de compilación, se le suele llamar ligadura estática, y la vinculación que se produce en la llamada a un método con la clase a la que pertenece ese método se realiza en tiempo de compilación. Es decir, que antes de generar el código ejecutable se conoce exactamente el método (a qué clase pertenece) que será llamado, también conocido como vinculación temprana. En los lenguajes tradicionales, no orientados a objetos, ésta es la única forma de poder resolver la ligadura (en tiempo de compilación).

Sin embargo, en los lenguajes orientados a objetos existe otra posibilidad: la ligadura dinámica, y en donde la vinculación que se produce en la llamada a un método con la clase a la que pertenece ese método se realiza en tiempo de ejecución. Es decir, que al generar el código ejecutable no se conoce exactamente el método (a qué clase pertenece) que será llamado. Sólo se sabrá cuando el programa esté en ejecución. También conocida como vinculación tardía, enlace tardío o late binding.

La ligadura dinámica hace posible que sea el tipo de objeto instanciado (obtenido mediante el constructor finalmente utilizado para crear el objeto) y no el tipo de la referencia (el tipo indicado en la declaración de la variable que apuntará al objeto) lo que determine qué versión del método va a ser invocada. El tipo de objeto al que apunta la variable de tipo referencia sólo podrá ser conocido durante la ejecución del programa y por eso el polimorfismo necesita la ligadura dinámica.

Ejemplo 6.02: polimorfismo anterior

En el ejemplo anterior de la clase ClaseX y sus subclases ClaseA y ClaseB, la llamada al método m sólo puede resolverse mediante ligadura dinámica, pues es imposible saber en tiempo de compilación si el método m que debe ser invocado será el definido en la subclase ClaseA o el definido en la subclase ClaseB:

//Llamada al método m (sin saber si será el método m de ClaseA o de ClaseB). 
objetoX.m() // Esta llamada será resuelta en tiempo de ejecución (ligadura dinámica)

Ejemplo 6.03: Revisa con cuidado el siguiente ejemplo 2

Imagínate una clase que represente a un instrumento musical genérico (Instrumento) y dos subclases que representen tipos de instrumentos específicos (por ejemplo Flauta y Piano). Todas las clases tendrán un método tocarNota, que será específico para cada subclase.

Haz un pequeño programa de ejemplo en Java que utilice el polimorfismo (referencias a la superclase que se convierten en instancias específicas de subclases) y la ligadura dinámica (llamadas a un método que aún no están resueltas en tiempo de compilación) con estas clases que representan instrumentos musicales. Puedes implementar el método tocarNota mediante la escritura de un mensaje en pantalla.

Solución
La clase Instrumento podría tener un único método (tocarNota):

public abstract class Instrumento {

public void tocarNota(String nota) {
    System.out.format("Instrumento: tocar nota %s.\n", nota);
}
}

En el caso de las clases Piano y Flauta puede ser similar, heredando de Instrumento y redefiniendo el método tocarNota:

public class Flauta extends Instrumento {

@Override
public void tocarNota(String nota) {
    System.out.format("Flauta: tocar nota %s.\n", nota);
}
}

public class Piano extends Instrumento {

@Override
public void tocarNota(String nota) {
    System.out.format("Piano: tocar nota %s.\n", nota);
}
}

Creamos una clase para comprobar su funcionamiento EjemploUso:

import java.util.Scanner;

public class EjemploUso {

    public static void main(String[] args) {
        Scanner teclado = new Scanner(System.in);
        System.out.print("Deseas un Piano o una Flauta (p o f)?: ");
        char respuesta = teclado.nextLine().toLowerCase().charAt(0);

        Instrumento instrumento1; // Ejemplo de objeto polimórfico (podrá ser Piano o Flauta)
        if (respuesta == 'p') {
            // Ejemplo de objeto polimórfico (en este caso va adquirir forma de Piano)
            instrumento1 = new Piano();
        } else {
            // Ejemplo de objeto polimórfico (en este caso va adquirir forma de Flauta)
            instrumento1 = new Flauta();
        }
        // Interpretamos una nota con el objeto instrumento1
        // No sabemos si se ejecutará el método tocarNota de Piano o de Flauta (dependerá de la ejecución)
        instrumento1.tocarNota("do"); // Ejemplo de ligadura dinámica (tiempo de ejecución)
    }
}

paso 1) A la hora de declarar una referencia a un objeto de tipo instrumento, utilizamos la superclase (Instrumento):

Instrumento instrumento1; // Ejemplo de objeto polimórfico (podrá ser Piano o Flauta)

paso 2) Sin embargo, a la hora de instanciar el objeto, utilizamos el constructor de alguna de sus subclases (Piano, Flauta, etc.):

if (respuesta == 'p') {
    // Ejemplo de objeto polimórfico (en este caso va adquirir forma de Piano)
    instrumento1 = new Piano();
} else {
    // Ejemplo de objeto polimórfico (en este caso va adquirir forma de Flauta)
    instrumento1 = new Flauta();
}

paso 3) Finalmente, a la hora de invocar el método tocarNota, no sabremos a qué versión (de qué subclase) de tocarNota se estará llamando, pues dependerá del tipo de objeto (subclase) que se haya instanciado. Se estará utilizando por tanto la ligadura dinámica:

// Interpretamos una nota con el objeto instrumento1
// No sabemos si se ejecutará el método tocarNota de Piano o de Flauta (dependerá de la ejecución)
instrumento1.tocarNota("do"); // Ejemplo de ligadura dinámica (tiempo de ejecución)

3. Limitaciones de la ligadura dinámica

Como has podido comprobar, el polimorfismo se basa en la utilización de referencias de un tipo más "amplio" (superclases) que los objetos a los que luego realmente van a apuntar (subclases). Ahora bien, existe una importante restricción en el uso de esta capacidad, pues el tipo de referencia limita cuáles son los métodos que se pueden utilizar y los atributos a los que se pueden acceder.

Restricción a tener en cuenta

No se puede acceder a los miembros específicos de una subclase a través de una referencia a una superclase. Sólo se pueden utilizar los miembros declarados en la superclase, aunque la definición que finalmente se utilice en su ejecución sea la de la subclase.

Ejemplo 6.04

Si dispones de una clase Profesor que es subclase de Persona y declaras una variable como referencia un objeto de tipo Persona, aunque más tarde esa variable haga referencia a un objeto de tipo Profesor (subclase), los miembros a los que podrás acceder sin que el compilador produzca un error serán los miembros de Profesor que hayan sido heredados de Persona (superclase). De este modo, se garantiza que los métodos que se intenten llamar van a existir cualquiera que sea la subclase de Persona a la que se apunte desde esa referencia.

En el ejemplo de las clases Persona, Profesor y Alumno, el polimorfismo nos permitiría declarar variables de tipo Persona y más tarde hacer con ellas referencia a objetos de tipo Profesor o Alumno, pero no deberíamos intentar acceder con esa variable a métodos que sean específicos de la clase Profesor o de la clase Alumno, tan solo a métodos que sabemos que van a existir seguro en ambos tipos de objetos (métodos de la superclase Persona).

Ejemplo 6.05: Revisa con cuidado el siguiente ejemplo

Haz un pequeño programa en Java en el que se declare una variable de tipo Persona, se pidan algunos datos sobre esa persona (nombre, apellidos y si es alumno o si es profesor), y se muestren nuevamente esos datos en pantalla, teniendo en cuenta que esa variable no puede ser instanciada como un objeto de tipo Persona (es una clase abstracta) y que tendrás que instanciarla como Alumno o como Profesor. Recuerda que para poder recuperar sus datos necesitarás hacer uso de la ligadura dinámica y que tan solo deberías acceder a métodos que sean de la superclase.

Solución
Si tuviéramos diferentes variables referencia a objetos de las clases Alumno y Profesor tendrías algo así:

Alumno objA;
Profesor objP;
...
// Si se dan ciertas condiciones el objeto será de tipo Alumno y lo tendrás en objA
System.out.printf ("Nombre: %s\n", objA.getNombre());
// Si se dan otras condiciones el objeto será de tipo Profesor y lo tendrás en objP
System.out.printf ("Nombre: %s\n", objP.getNombre());

Pero si pudieras tratar de una manera más genérica la situación, podrías intentar algo así:

Persona obj;
// Si se dan ciertas condiciones el objeto será de tipo Alumno y por tanto lo instanciarás como tal
obj = new Alumno (<parámetros>);
// Si se otras condiciones el objeto será de tipo Profesor y por tanto lo instanciarás como tal
obj = new Profesor (<parámetros>);

De esta manera la variable obj podría contener una referencia a un objeto de la superclase Persona de subclase Alumno o bien de subclase Profesor (polimorfismo).

Esto significa que independientemente del tipo de subclase que sea (Alumno o Profesor), podrás invocar a métodos de la superclase Persona y durante la ejecución se resolverán como métodos de alguna de sus subclases:

//En tiempo de compilación no se sabrá de qué subclase de Persona será obj.
//Habrá que esperar la ejecución para que el entorno lo sepa e invoque al método adecuado.
System.out.format("Contenido del objeto: %s\n", obj.devolverContenidoString());

Por último recuerda que debes de proporcionar constructores a las subclases Alumno y Profesor que sean "compatibles" con algunos de los constructores de la superclase Persona, pues al llamar a un constructor de una subclase, su formato debe coincidir con el de algún constructor de la superclase (como debe suceder en general con cualquier método que sea invocado utilizando la ligadura dinámica).

Constructor "compatible" para Alumno:

public Alumno(String nombre, String apellidos, LocalDate fechaNacim){
    super(nombre, apellidos, fechaNacim);
}

y el constructor "compatible" para Profesor:

public Profesor(String nombre, String apellidos, LocalDate fechaNacim) {
    super(nombre, apellidos, fechaNacim);
}

Aquí tienes el ejemplo completo de la clase EjemploUso:

import java.time.LocalDate;
import java.util.Scanner;

public class EjemploUso {

public static void main(String[] args) {
    Persona obj;
    Scanner teclado = new Scanner(System.in);
    System.out.print("Deseas crear un Profesor o un Alumno ('p' o 'a')?: ");
    char respuesta = teclado.nextLine().toLowerCase().charAt(0);

    if (respuesta == 'a') {
        // Ejemplo de objeto polimórfico (en este caso va adquirir forma de Alumno)
        obj = new Alumno("Alumno", "Apellidos", LocalDate.of(1977, 3, 8));
    } else {
        // Ejemplo de objeto polimórfico (en este caso va adquirir forma de Profesor)
        obj = new Profesor("Profe", "Apellidos", LocalDate.of(1977, 3, 8));
    }
    System.out.format("Contenido del objeto: %s\n", obj.devolverContenidoString());
}
}

4. Interfaces y polimorfismo

Es posible también llevar a cabo el polimorfismo mediante el uso de interfaces. Un objeto puede tener una referencia cuyo tipo sea una interfaz, pero para que el compilador te lo permita, la clase cuyo constructor se utilice para crear el objeto deberá implementar esa interfaz (bien por si misma o bien porque la implemente alguna superclase). Un objeto cuya referencia sea de tipo interfaz sólo puede utilizar aquellos métodos definidos en la interfaz, es decir, que no podrán utilizarse los atributos y métodos específicos de su clase, tan solo los de la interfaz.

Las referencias de tipo interfaz permiten unificar de una manera bastante estricta la forma de utilizarse de objetos que pertenezcan a clases muy diferentes (pero que todas ellas implementan la misma interfaz). De este modo podrías hacer referencia a diferentes objetos que no tienen ninguna relación jerárquica entre sí utilizando la misma variable (referencia a la interfaz). Lo único que los distintos objetos tendrían en común es que implementan la misma interfaz.

A tener en cuenta

En este caso sólo podrás llamar a los métodos de la interfaz y no a los específicos de las clases.

Ejemplo 6.06

Si tenías una variable de tipo referencia a la interfaz Arrancable, podrías instanciar objetos de tipo Coche o Motosierra y asignarlos a esa referencia (teniendo en cuenta que ambas clases no tienen una relación de herencia).
Sin embargo, tan solo podrás usar en ambos casos los métodos y los atributos de la interfaz Arrancable (por ejemplo arrancar) y no los de Coche o los de Motosierra (sólo los genéricos, nunca los específicos).

En el caso de las clases Persona, Alumno y Profesor, podrías declarar, por ejemplo, variables del tipo Imprimible:

Imprimible obj; // Imprimible es una interfaz y no una clase

Con este tipo de referencia podrías luego apuntar a objetos tanto de tipo Profesor como de tipo Alumno, pues ambos implementan la interfaz Imprimible:

// En algunas circunstancias podría suceder esto:
obj = new Alumno (nombre, apellidos, fecha, grupo, nota); // Polimorfismo con interfaces
...

// En otras circunstancias podría suceder esto:
obj = new Profesor (nombre, apellidos, fecha, especialidad, salario); // Polimorfismo con interfaces
...

Y más adelante hacer uso de la ligadura dinámica:

// Llamadas sólo a métodos de la interfaz
String contenido;
contenido = obj.devolverContenidoString(); // Ligadura dinámica con interfaces

5. Conversión de objetos

Como ya has visto, en principio no se puede acceder a los miembros específicos de una subclase a través de una referencia a una superclase. Si deseas tener acceso a todos los métodos y atributos específicos del objeto subclase tendrás que realizar una conversión explícita (casting) que convierta la referencia más general (superclase) en la del tipo específico del objeto (subclase).

Para que puedas realizar conversiones entre distintas clases es obligatorio que exista una relación de herencia entre ellas (una debe ser clase derivada de la otra). Se realizará una conversión implícita o automática de subclase a superclase siempre que sea necesario, pues un objeto de tipo subclase siempre contendrá toda la información necesaria para ser considerado un objeto de la superclase.

Ahora bien, la conversión en sentido contrario (de superclase a subclase) debe hacerse de forma explícita y según el caso podría dar lugar a errores por falta de información (atributos) o de métodos. En tales casos se produce una excepción de tipo ClassCastException.

Por ejemplo, imagina que tienes una clase Animal y una clase Marmota, subclase de Animal:

class Animal {
    public String nombre;
}

class Marmota extends Animal {
    public double peso;
}

A continuación declaras una variable referencia a la clase Animal (superclase) pero sin embargo le asignas una referencia a un objeto de la clase Marmota (subclase) haciendo uso del polimorfismo:

Animal obj; // Referencia a objetos de la clase Animal
obj = new Marmota(); // Referencia a objetos clase Animal, pero apunta realmente a objeto clase Marmota (polimorfismo)

El objeto que acabas de crear como instancia de la clase Marmota (subclase de Animal) contiene más información que la que la referencia obj te permite en principio acceder sin que el compilador genere un error (pues es de clase Animal). En concreto los objetos de la clase Marmota disponen de nombre y peso, mientras que los objetos de la clase Animal sólo de nombre. Para acceder a esa información adicional de la clase especializada (peso) tendrás que realizar una conversión explícita (casting):

// Casting del tipo Animal al tipo Marmota (funcionará bien porque el objeto es realmente del tipo B)
System.out.printf ("obj.peso=%f\n", ((Marmota) obj).peso);

Sin embargo si se hubiera tratado de una instancia de la clase Animal y hubieras intentado acceder al miembro peso, se habría producido una excepción de tipo ClassCastException:

Animal obj; // Referencia a objetos de la clase Animal
obj = new Animal (); // Referencia a objetos de la clase Animal, y apunta realmente a un objeto de la clase Animal

// Casting del tipo Animal al tipo Besugo (puede dar problemas porque el objeto es realmente del tipo Animal):
// Funciona (la clase Animal tiene nombre)
System.out.printf ("obj.nombre=%s\n", ((Marmota) obj).nombre);

// ¡Error en ejecución! (la clase Animal no tiene peso). Producirá una ClassCastException.
System.out.printf ("obj.peso=%f\n", ((Marmota) obj).peso);