Comprobaciones de tipo

En resumen: Una comprobación de tipo con is pregunta si un objeto es de una clase dada o de una de sus clases hijas, y una conversión hacia abajo da acceso a los métodos de la clase hija.

Problema

Solo algunos se pueden cargar

Una empresa tiene una flota de coches normales y eléctricos. Cada noche hay que cargar los eléctricos. ElectricCar hereda de Car y añade Charge(), así que todos están en un solo array Car[]:

Car[] fleet =
{
    new Car("Skoda"),
    new ElectricCar("Tesla", 35),
    new Car("Dacia"),
    new ElectricCar("Nissan", 60)
};
foreach (Car c in fleet)
{
    c.Charge();
}

El programa no compila:

"'Car' does not contain a definition for 'Charge'".

Ya sabes por qué por la lección de polimorfismo: el tipo de la variable decide qué puedes llamar. c es un Car, y Car no tiene carga.

Un coche normal de verdad no se puede cargar. Tienes que preguntar a cada coche: «¿eres eléctrico?»

La idea

Pregunta al objeto qué es

foreach (Car c in fleet)
{
    if (c is ElectricCar e)
    {
        e.Charge();
        Console.WriteLine(e.Brand + ": cargado al " + e.Battery + "%");
    }
}

Salida

Tesla: cargado al 100%
Nissan: cargado al 100%

c is ElectricCar e hace dos cosas a la vez:

• comprueba si el objeto al que apunta c es un ElectricCar;
• si lo es, crea una variable e de tipo ElectricCar que apunta al mismo objeto.

A través de e ya puedes llamar a Charge(). Los coches siguen siendo los mismos. Solo miras el objeto a través de un tipo más concreto.

Esto se llama comprobación de tipo. Pasar del tipo de la clase padre al tipo de la clase hija se llama conversión hacia abajo (downcast): hacia abajo por la cadena Object → Car → ElectricCar.

e existe solo dentro del if. Fuera de él, el objeto vuelve a ser solo un Car.

foreach (Car c in fleet)
{
    if (c is ElectricCar e)
    {
        e.Charge();
        Console.WriteLine(e.Brand + ": cargado al " + e.Battery + "%");
    }
}

Paso a paso, en palabras

1. fleet es un array de Car: 2 coches normales y 2 eléctricos.
2. c apunta al Skoda: is da «no». El cuerpo del if se salta.
3. c apunta al Tesla: is da «sí». e es una segunda flecha al mismo coche y lo carga.
4. c apunta al Dacia: is da «no». El cuerpo del if se salta.
5. c apunta al Nissan: is da «sí». e es una segunda flecha al mismo coche y lo carga.
6. Los coches no cambian. La comprobación solo mira el objeto a través de un tipo más concreto.

Pruébalo

¿Es un coche?

¿Qué imprimirá el programa?

Car c = new ElectricCar("Tesla", 35);
Car d = new Car("Skoda");
Console.WriteLine(c is Car);
Console.WriteLine(c is ElectricCar);
Console.WriteLine(d is ElectricCar);

Respuesta

False
True
False

True
False
False

True
True
False

Comprobar

La idea

Otras formas con las que te encontrarás

Además de is también existe as. Intenta la conversión, y si el objeto no es de ese tipo, da null en lugar de un error:

ElectricCar e = fleet[1] as ElectricCar;
if (e != null)
{
    e.Charge();
    Console.WriteLine(e.Brand + ": " + e.Battery + "%");
}
ElectricCar none = fleet[0] as ElectricCar;
Console.WriteLine(none == null);

Salida

Tesla: 100%
True

fleet[0] es «Skoda», así que as da null. Entonces tienes que comprobar si es null antes de llamar a métodos. Con is ElectricCar e la comprobación y la conversión están en un solo lugar, así que es más corto.

Más precisamente, para curiosos

• También existe la conversión clásica (ElectricCar)c. Si el objeto no es un ElectricCar, el programa se detiene con InvalidCastException.
• La comprobación siempre es falsa para null: null is Car es false. Así que después de un is que sale bien nunca tienes null.

• La comprobación también funciona con interfaces: a is ISwimmable s pregunta si la clase del objeto implementa el contrato.

Pruébalo

Encuentra el error

El programa cuenta los coches normales y los eléctricos. La flota tiene dos de cada uno, pero imprime:

Salida

Normales: 4, eléctricos: 0

¿En qué línea está el error?

Elige la línea con el error.

1int regular = 0;2int electric = 0;3foreach (Car c in fleet)4{5 if (c is Car)6 {7 regular++;8 }9 else if (c is ElectricCar)10 {11 electric++;12 }13}14Console.WriteLine("Normales: " + regular + ", eléctricos: " + electric);

Comprobar

La idea

¿Una comprobación o un método?

Quieres imprimir con qué funciona cada coche. Una comprobación de tipo puede hacerlo:

foreach (Car c in fleet)
{
    if (c is ElectricCar)
    {
        Console.WriteLine(c.Brand + ": electricidad");
    }
    else
    {
        Console.WriteLine(c.Brand + ": gasolina");
    }
}

Pero esto es el salario con un if por cada rol de la lección de polimorfismo. Todo coche tiene una fuente de energía, solo que distinta. Eso es trabajo para un método en Car, sobrescrito en ElectricCar:

// en Car
public virtual string Energy()
{
    return "gasolina";
}

// en ElectricCar
public override string Energy()
{
    return "electricidad";
}

foreach (Car c in fleet)
{
    Console.WriteLine(c.Brand + ": " + c.Energy());
}

Salida

Skoda: gasolina
Tesla: electricidad
Dacia: gasolina
Nissan: electricidad

Mañana llega un coche híbrido. Con el método, escribes una clase nueva. Con las comprobaciones, buscas cada if del programa.

La regla:

• Todo objeto lo hace, cada uno a su manera: un método en la clase padre, y sobrescritura.
• Solo algunos objetos pueden hacerlo (cargar, pedalear): una comprobación de tipo.

Pruébalo

¿Qué falta?

foreach (Car c in fleet)
{
    if (c  ElectricCar e)
    {
        e.Charge();
    }
}

Comprobar

En resumen

Los cuatro pilares de la POO

Con esta lección has visto todas las ideas de los módulos «Clases y objetos» y «Herencia y polimorfismo». La programación orientada a objetos se apoya en cuatro de ellas. Ya las usas todas:

• Encapsulamiento. Los datos del objeto están ocultos, y desde fuera llegas a ellos solo a través de métodos que vigilan las reglas. Account guarda el saldo private y ofrece solo Deposit() y Withdraw(). Encapsulamiento
• Herencia. Lo común está en un solo lugar, la clase padre, y la clase hija añade lo suyo. Manager es un Employee con un bono. Herencia
• Polimorfismo. Una sola llamada, un comportamiento distinto según el objeto. e.MonthlyPay() en un solo bucle calcula el pago de un empleado, un gerente y un becario. Polimorfismo
• Abstracción. Dices qué tiene que saber hacer el objeto, y cada clase decide cómo. El abstracto Shape promete un área, la interfaz IPayable promete un importe a pagar. Clases abstractas, Interfaces

Cómo trabajan las cuatro juntas en un solo programa, cuándo duele cada una y qué se suele confundir está en la última lección del módulo: Principios de la POO.

Ejercicio

¿Qué es en realidad?

Resuélvelas en tu editor.

1. Aparcamiento. Un array SimpleCar[] de coches normales y familiares (FamilyCar hereda de SimpleCar). Para cada uno, imprime su tipo. Cuidado con el orden de las comprobaciones.

Salida

Esto es un SimpleCar
Esto es un FamilyCar
Esto es un SimpleCar

2. Bailes. Un array DanceMove[] de pasos normales y de breakdance. Para los pasos de breakdance, imprime también la complejidad. Para eso necesitas la variable de la comprobación.

Salida

moonwalk: DanceMove
windmill: BreakDanceMove, complejidad 8
salsa: DanceMove

3. Flota. Toma Car y ElectricCar del ejercicio de la lección «Herencia». En un array Car[], pon un «Skoda» con 40 l, un «Tesla» con eficiencia 5, un «Dacia» con 5 l y un «Nissan» con eficiencia 4. Cada uno recorre 100 km: los eléctricos con DriveElectric, los demás con Drive. Después imprime los kilómetros y el combustible o la batería.

Salida

Skoda: 100 km, combustible 30 l
Tesla: 100 km, batería 80%
El combustible no alcanza para 100 km
Dacia: 0 km, combustible 5 l
Nissan: 100 km, batería 75%

4. Zoológico. Una clase abstracta Animal con Sound(), y clases hijas Cat, Dog y Fish. Solo Fish implementa ISwimmable con Swim(). En un bucle sobre los animales, llama al sonido de cada uno, y para los que saben nadar, llama también a Swim().

Salida

¡Miau, miau!
¡Guau, guau!
El pez se calla.
El pez nada.

Más tareas

• Pedales. En el ejercicio de la lección «Clases abstractas», garage[1].Pedal() no compilaba. Arréglalo con una comprobación de tipo: en el bucle sobre Vehicle[], todo vehículo arranca, y la bicicleta además pedalea.
• Pagos por tipo. De la lección «Interfaces»: el array IPayable[] guarda empleados y facturas. Imprime por separado el total de salarios y el total de facturas. Para Juan, María y las dos facturas: 5500 € en salarios y 2140 € en facturas.

Test

Ponte a prueba

1. c is ElectricCar e es verdadero. ¿Qué es e?

El mismo objeto, pero a través de una variable de tipo ElectricCarUna variable vacía que tienes que llenarUn objeto nuevo, una copia de c

2. c apunta a un ElectricCar. ¿Qué da c is Car?

No compilaFalseTrue

3. Compruebas si un coche es un Car o un ElectricCar. ¿En qué orden?

El orden no importaPrimero Car, después ElectricCarPrimero ElectricCar, después Car

4. El programa tiene muchos if del tipo «si es un ElectricCar, haz una cosa, si no, haz otra». ¿Qué te dice eso?

Que ElectricCar no debería heredar de CarQue necesitas más comprobacionesQue ese comportamiento debería ser un método en Car, sobrescrito en ElectricCar

5. c apunta a un coche normal. ¿Qué da c as ElectricCar?

El programa se detiene con InvalidCastExceptionnullEl coche se vuelve eléctrico

Comprobar

Empezar la lección de nuevo

Lecciones relacionadas

• Se basa en: Herencia · Polimorfismo · Clases abstractas · Interfaces
• Continúa en: Principios de la POO · Lanzar excepciones y crear las tuyas · Códigos hash y funciones hash · record, switch y patrones
• Ejercicios sobre el tema: Herencia y polimorfismo