Herencia y @Override

El problema: dos clases casi iguales

Imagina que el sistema del curso ahora necesita también profesores. Un profesor tiene nombre y edad, igual que un alumno, pero además tiene una materia:

public class Alumno {
    private String nombre;
    private int edad;
    private double nota;
    // constructor, getters, setters...
}

public class Profesor {
    private String nombre;
    private int edad;
    private String materia;
    // el MISMO constructor, los MISMOS getters, otra vez...
}

nombre y edad, con su constructor y sus getters, están escritos dos veces. Si mañana se agrega un dni, hay que tocar los dos archivos y acordarse de no olvidar ninguno. La herencia permite escribir esa parte común una sola vez, en una clase “padre”, y que las otras dos partan de ahí.

extends: heredar de otra clase

extends se traduce literalmente como “extiende” o “amplía”, y describe bastante bien lo que pasa: la clase hija es la clase padre más lo suyo propio.

public class Persona {
    protected String nombre;
    protected int edad;

    public Persona(String nombre, int edad) {
        this.nombre = nombre;
        this.edad = edad;
    }

    public String getNombre() {
        return nombre;
    }

    public String describir() {
        return nombre + ", " + edad + " años";
    }
}

public class Alumno extends Persona {
    private double nota;

    public Alumno(String nombre, int edad, double nota) {
        super(nombre, edad);
        this.nota = nota;
    }
}

Alumno no declara nombre ni edad ni getNombre(), y sin embargo los tiene:

Alumno a = new Alumno("Ana", 20, 8.5);
System.out.println(a.getNombre());
System.out.println(a.describir());

Ana
Ana, 20 años

El vocabulario que vas a ver en cualquier explicación de Java:

protected en vez de private

En Persona, nombre y edad están declarados protected, no private. Ese es el modificador de la tabla de Encapsulación que faltaba justificar: private haría que ni siquiera Alumno — que es una Persona — pudiera leerlos directamente.

super: llamar al padre

super se traduce como “superior”, y se refiere a la clase de arriba. Tiene dos usos distintos que conviene no mezclar:

1. super(...) — llamar al constructor del padre. Solo se puede usar como primera línea del constructor de la hija:

public Alumno(String nombre, int edad, double nota) {
    super(nombre, edad);   // Persona se encarga de nombre y edad
    this.nota = nota;      // Alumno se encarga de lo suyo
}

2. super.metodo() — llamar a la versión del padre de un método, que es lo que verás en la sección siguiente.

Sobrescribir un método: @Override

describir() funciona para cualquier persona, pero para un alumno estaría bueno que además dijera la nota. La hija puede sobrescribir (override) el método: volver a declararlo con la misma firma, y su versión reemplaza a la del padre para los objetos de esa clase.

public class Alumno extends Persona {
    private double nota;

    public Alumno(String nombre, int edad, double nota) {
        super(nombre, edad);
        this.nota = nota;
    }

    @Override
    public String describir() {
        return super.describir() + " — nota: " + nota;
    }
}

Persona p = new Persona("Luis", 45);
Alumno a = new Alumno("Ana", 20, 8.5);
System.out.println(p.describir());
System.out.println(a.describir());

Luis, 45 años
Ana, 20 años — nota: 8.5

Dos cosas están pasando ahí:

• describir() en Alumno reemplaza al de Persona para todo objeto Alumno.
• super.describir() llama a la versión original del padre desde dentro de la nueva. Sin ese super., escribir describir() a secas se llamaría a sí mismo para siempre — una recursión infinita que termina en StackOverflowError.

Qué es realmente @Override

@Override es una anotación: una marca que se le pone al código para que el compilador (o una herramienta) la lea. Override se traduce como “anular” o “prevalecer sobre”.

Lo importante: @Override no hace que el método sobrescriba nada. La sobrescritura ocurre igual sin la anotación, solo por tener la misma firma que el método del padre. Lo que hace @Override es pedirle al compilador que verifique esa intención — y ahí está todo su valor:

public class Alumno extends Persona {
    @Override
    public String descrbir() {   // ← typo: "descrbir"
        return "...";
    }
}

Sin @Override, eso compila perfecto: Java entiende que estás declarando un método nuevo llamado descrbir(), y describir() sigue devolviendo la versión del padre. El programa corre y hace lo que no querías, sin un solo error. Con @Override, el compilador responde method does not override or implement a method from a supertype y el problema aparece al instante.

Sobrescribir (override) no es sobrecargar (overload)

Los dos nombres se parecen muchísimo en español y en inglés, y significan cosas distintas. Ya viste la sobrecarga en Métodos:

static int sumar(int a, int b) { ... }
static double sumar(double a, double b) { ... }

public class Persona { public String describir() { ... } }
public class Alumno extends Persona { @Override public String describir() { ... } }

Un truco para no confundirlas: sobrecargar es cargar un mismo nombre con varios significados a la vez; sobrescribir es escribir encima del que ya había, tapándolo.

Reglas que el compilador hace cumplir

Al sobrescribir, la hija no puede hacer cualquier cosa:

Pon a prueba

public class Animal {
    public String hablar() {
        return "Sonido genérico";
    }
}

public class Perro extends Animal {
    @Override
    public String hablar() {
        return "Guau";
    }
}

// en main:
Animal a = new Perro();
System.out.println(a.hablar());

public class Empleado  Persona {
  private String puesto;

  public Empleado(String nombre, int edad, String puesto) {
      (nombre, edad);
      this.puesto = puesto;
  }

  
  public String describir() {
      return .describir() + " — " + puesto;
  }
}

public class Animal {
    public String hablar() {
        return "Sonido genérico";
    }
}

public class Gato extends Animal {
    public String hablar(String tono) {
        return "Miau";
    }
}

// en main:
Animal a = new Gato();
System.out.println(a.hablar());

Siguiente paso

Que Alumno y Profesor sean los dos una Persona habilita algo más potente que ahorrar código repetido: poder tratarlos a los dos como personas y que cada uno responda a su manera. Eso es el polimorfismo — ver Polimorfismo y clases abstractas.