Piensa en la vida real, un Toyota, un Ferrari y un camión de carga son muy diferentes, ¿Cierto? Pero todos comparten una esencia:

• Son vehículos.
• Todos tienen ruedas.
• Un motor y un chasis.

Sería una locura y una terrible pérdida de tiempo que los ingenieros diseñaran cada tornillo desde cero para cada nuevo modelo.

En programación, nos enfrentamos al mismo problema ¿Vamos a copiar y pegar el código de las "ruedas" y el "motor" en cada nueva clase que creemos? ¡Por supuesto que no! Usamos uno de los pilares más elegantes y potentes de la Programación Orientada a Objetos: la HERENCIA.

¿Qué es la Herencia en la Programación Orientada a Objetos?

La herencia es un mecanismo que permite que una clase, que llamaremos subclase o clase hija, adquiera los atributos y métodos de otra clase, a la que llamamos superclase o clase padre.

Esto establece una relación "es un". Por ejemplo:

• Un carro deportivo es un Vehículo.

El propósito fundamental es la reutilización de código y la creación de una organización lógica y jerárquica.

Muy bien, ahora que tenemos clara la teoría, vamos a nuestro editor de código, para nuestro ejemplo, crearemos esa clase genérica que será nuestro pilar: Vehículo.

• Lo primero que debemos entender es cómo una clase padre controla qué partes de sí misma comparte con sus hijas.
• Para eso usamos los modificadores de acceso que ya conocemos public (abierto a todos) y private (cerrado a todos excepto a la propia clase).
• Pero en herencia, hay un modificador de acceso clave: protected.

¿Qué es el modificador de acceso protected?

Un miembro protected es como un secreto de familia: es private para el mundo exterior, pero las clases hijas que heredan de ella sí pueden verlo y usarlo, ss el equilibrio perfecto para la herencia.

Ahora sí, definamos nuestra clase Vehículo, vamos a darle un modelo, que será privado, y un kilometraje, que haremos protegido.

• Escribimos private string modelo; y ahora, para el kilometraje, protected double kilometraje; ¿Por qué? Porque quizás una clase hija como CamionetaDeMantenimiento necesita acceder o modificar directamente el kilometraje, y protected se lo permitirá.
• Añadimos el constructor public Vehiculo(string modelo) e inicializamos los atributos.
• Y finalmente, el método public virtual void Conducir().
• Recuerda, virtual da permiso a las hijas para que puedan sobre escribir este comportamiento.

// Vehículo.cs
namespace console_poo_ewebik;
// CLASE PADRE / SUPERCLASE
public class Vehiculo
{
    private string modelo;
    // Protected: Es private para el exterior,
    // pero public para las clases hijas.
    protected double kilometraje;

    public string Modelo { get { return modelo; } }
    public double Kilometraje { get { return kilometraje; } }

    public Vehiculo(string modelo)
    {
        this.modelo = modelo;
        this.kilometraje = 0;
        Console.WriteLine(
            $"Un nuevo {this.Modelo} ha sido fabricado.");
    }

    // Este método puede ser sobreescrito por las clases hijas.
    public virtual void Conducir()
    {
        Console.WriteLine("El vehículo genérico está en movimiento.");
    }
}

¡Genial! Tenemos nuestro plano maestro, ahora, vamos a crear nuestra primera clase hija, queremos crear un CarroDeportivo.

• Para implementarlo en C#, escribimos public class CarroDeportivo : Vehiculo.
• Ese dos puntos (:) es la palabra mágica, le dice a C# que CarroDeportivo hereda todo lo público y protegido de Vehículo.

Pero ahora tenemos un problema, el constructor de Vehículo necesita un modelo ¿Cómo se lo pasamos desde el constructor de CarroDeportivo? Usamos otra palabra clave: base.

• Creamos el constructor de la clase hija: public CarroDeportivo(string modelo).
• Y justo después, añadimos : base(modelo).
• Esto lo que hace es llamar al constructor de la clase padre (Vehiculo) y pasarle el parámetro modelo antes de ejecutar cualquier cosa dentro del constructor hijo.

¡Es la forma de construir el objeto desde la base hacia arriba!

// CarroDeportivo.cs
namespace console_poo_ewebik;
// CLASE HIJA / SUBCLASE
// CarroDeportivo "es un" Vehiculo.
public class CarroDeportivo : Vehiculo
{
    // Llama al constructor de la clase padre (Vehiculo) usando 'base'.
    public CarroDeportivo(string modelo) : base(modelo)
    {
        Console.WriteLine("Y ha sido configurado como un deportivo de alto rendimiento.");
    }
}

¡Perfecto! Ahora vamos a probarlo, si creamos un nuevo CarroDeportivo y llamamos a su método Conducir, ¿Qué pasará? Heredará el comportamiento de Vehículo.

//Program.cs
using console_poo_ewebik;

CarroDeportivo carroDeportivo = new CarroDeportivo("Ferrari");
//Que imprime:
// Un nuevo Ferrari ha sido fabricado.
//Y ha sido configurado como un deportivo de alto rendimiento.

carroDeportivo.Conducir();
//Que imprime:
//El vehículo genérico está en movimiento.

Sobre escritura de Métodos y Herencia Jerárquica

El resultado anterior está bien, pero un deportivo no se conduce como un "vehículo genérico"

• Suena diferente
• Se siente diferente.

Queremos especializar ese comportamiento., aquí es donde usamos la pareja de virtual y override.

Dentro de nuestra clase CarroDeportivo, vamos a redefinir el método Conducir.

• Escribimos public override void Conducir(), la palabra clave override le dice a C# "Voy a ignorar la implementación de mi padre y a proporcionar la mía propia". Como el método en Vehiculo era virtual, esto es totalmente válido.
• Ahora, dentro de este nuevo método, escribimos un mensaje diferente, como "¡El [Modelo] ruge por la carretera a toda velocidad!".
• Ahora, para ampliar nuestra estructura, vamos a crear otra clase hija, esto nos lleva a un tipo específico de herencia.

// CarroDeportivo.cs
namespace console_poo_ewebik;
// CLASE HIJA / SUBCLASE
// CarroDeportivo "es un" Vehiculo.
public class CarroDeportivo : Vehiculo
{
    // Llama al constructor de la clase padre (Vehiculo) usando 'base'.
    public CarroDeportivo(string modelo) : base(modelo)
    {
        Console.WriteLine("Y ha sido configurado como un deportivo de alto rendimiento.");
    }

    // Sobreescribimos el comportamiento de Conducir.
    public override void Conducir()
    {
        Console.WriteLine($"¡El {Modelo} ruge por la carretera a toda velocidad!");
    }

}

¿Qué es la Herencia Jerárquica en la programación orientada a objetos?

Esto es muy simple, la Herencia Jerárquica ocurre cuando una única clase padre tiene múltiples clases hijas, cada hija hereda de la misma base, pero puede tener sus propias características y comportamientos.

Es como si Vehiculo fuera el tronco de un árbol, y de él salieran las ramas CarroDeportivo, Camioneta, Motocicleta, etc.

Para demostrarlo, vamos a crear la clase Camioneta, que también heredará de Vehículo, le daremos un atributo propio, CapacidadCarga, y también sobreescribiremos su método Conducir para que tenga un comportamiento único.

//Camioneta.cs
namespace console_poo_ewebik;

public class Camioneta : Vehiculo
{
    public double CapacidadCarga { get; set; }

    public Camioneta(string modelo, double capacidad) : base(modelo)
    {
        this.CapacidadCarga = capacidad;
        Console.WriteLine("Y ha sido configurado como una camioneta de carga.");
    }

    public override void Conducir()
    {
        // Desde aquí podríamos acceder a 'this.kilometraje' directamente si quisiéramos,
        // porque está marcado como 'protected' en la clase Vehiculo.
        Console.WriteLine($"El {Modelo} avanza con fuerza, transportando su carga.");
    }
}

Si creamos instancias de cada uno y llamamos al mismo método Conducir, cada objeto se comportará de acuerdo a su tipo más específico ¡Esto es polimorfismo en acción, un tema que veremos más adelante!

//Program.cs
using console_poo_ewebik;

CarroDeportivo carroDeportivo = new CarroDeportivo("Ferrari");
//Que imprime:
// Un nuevo Ferrari ha sido fabricado.
//Y ha sido configurado como un deportivo de alto rendimiento.

carroDeportivo.Conducir();
//Que imprime:
//El vehículo genérico está en movimiento.

Camioneta carroCamioneta = new Camioneta("Ford Lobo", 100);
//Que imprime:
//Un nuevo Ford Lobo ha sido fabricado.

carroCamioneta.Conducir();
//Que imprime:
//El Ford Lobo avanza con fuerza, transportando su carga.

El Mito de la Herencia Múltiple en C#

Bien, una pregunta que surge naturalmente es: si una clase puede heredar de un padre, ¿puede heredar de dos o más? Por ejemplo, ¿podríamos tener un "Anfibio" que herede de Vehiculo y de Bote al mismo tiempo?

Y la respuesta en C# es: NO. C# implementa Herencia Simple, lo que significa que una clase solo puede heredar de una única clase padre.

¿Por qué? Para evitar un problema increíblemente complejo conocido como el "Problema del Diamante", imagina que Vehículo y Bote tienen ambos un método Moverse(), y Anfibio hereda de ambos., cuando llamas a Anfibio.Moverse(), ¿Cuál de los dos métodos debería ejecutar? Es ambiguo y peligroso.

C# evita este problema por completo, sin embargo, sí permite una especie de "herencia múltiple" de comportamiento a través de una construcción llamada Interfaces, que es un contrato que una clase promete cumplir.

Pero eso, amigos míos, es material para nuestro próximo gran vídeo.

Conclusiones

Repasemos lo que hemos aprendido hoy sobre la Herencia:

• Es una relación "es un": Un CarroDeportivo es un Vehiculo.
• Promueve la reutilización de código: No tuvimos que reescribir Modelo o Kilometraje.
• Usamos base(): Para llamar al constructor de la clase padre.
• Usamos virtual y override: Para especializar el comportamiento en las clases hijas.
• C# tiene Herencia Simple: Una clase, un padre directo.
• Usamos protected: Para dar acceso a las clases hijas, pero mantenerlo privado para el resto del mundo.

El reto de hoy es simple: ¿Qué otra clase podrías crear que herede de Vehículo? ¿Una Motocicleta? ¿Un Autobús? ¡Hasta la próxima!