virtual, abstract y override

En la lección anterior la hija heredaba los métodos del padre tal cual. Pero a menudo cada hija necesita hacer lo mismo de forma distinta: todos los descuentos «se aplican», pero uno resta un porcentaje y otro un importe fijo. Apex te deja decidir, método a método, qué se puede cambiar y qué no.

La nutria: El paralelo de Admin

Yo lo vi claro con las actividades: Task y Event comparten campos como Subject, ActivityDate u OwnerId porque los dos son Activities. Pero en tu org nunca creas una «Activity» a secas: creas una Task o un Event, y cada uno tiene sus propias reglas. Activity funciona como una clase abstracta: define lo común y exige que alguien concrete el resto.

virtual + override: «puedes cambiarlo»

Igual que las clases, los métodos de Apex son cerrados por defecto: una hija no los puede cambiar. Si el padre marca un método como virtual, ofrece una versión por defecto que las hijas pueden sustituir. La hija lo hace escribiendo el mismo método con override. Sin virtual en el padre o sin override en la hija, no compila.

public virtual class Notification {
    public String subject;
    public virtual String channel() {
        return 'Correo';            // versión por defecto
    }
}

public class SmsNotification extends Notification {
    public override String channel() {
        return 'SMS';               // la hija lo hace a su manera
    }
}

abstract: «tienes que hacerlo tú»

A veces el padre no tiene ninguna versión sensata que ofrecer: ¿cómo se aplica «un descuento» en abstracto? Entonces la clase se declara abstract y el método también, sin cuerpo, terminado en punto y coma. Una clase abstracta no se puede instanciar (new Discount() no compila) y cada hija concreta está obligada a implementar sus métodos abstractos con override.

public abstract class Discount {
    public String label;

    public Discount(String label) {
        this.label = label;
    }

    public abstract Decimal apply(Decimal amount);   // sin cuerpo: cada hija decide

    public virtual String describe() {
        return label;
    }
}

public class PercentDiscount extends Discount {
    private Decimal percent;

    public PercentDiscount(String label, Decimal percent) {
        super(label);
        this.percent = percent;
    }

    public override Decimal apply(Decimal amount) {
        return amount * (1 - percent / 100);
    }

    public override String describe() {
        return super.describe() + ' (' + percent + ' %)';   // amplía, no sustituye
    }
}

¿virtual, abstract o interfaz? Cómo decidir

Las tres herramientas responden a tres preguntas distintas. ¿Hay una forma por defecto que casi todas las hijas usarían? Entonces virtual: el padre la ofrece y quien quiera la cambia. ¿Hay código común que compartir, pero una parte que cada hija DEBE resolver y no tiene versión sensata en abstracto? Entonces clase abstract con un método abstract. ¿No hay nada en común salvo «saber hacer algo»? Entonces una interfaz, que es la lección 10. Elegir bien importa: una clase abstract obliga a heredar de ella, y en Apex solo se hereda de una clase.

La nutria: El layout obligatorio y el valor por defecto que se puede cambiar

Otro paralelo que me sirvió: todos los Record Types de Opportunity tienen que tener un page layout asignado (es obligatorio, no hay «ninguno»): eso es abstract. En cambio, un picklist tiene un valor por defecto que cada Record Type puede mantener o cambiar por otro: eso es virtual. Y «Activity», que nunca creas directamente porque siempre es una Task o un Event, es la clase abstract por excelencia de la plataforma.