Herança em TypeScript: extends, super e override

Uma classe TypeScript herda de outra com extends. A subclasse recebe todos os campos e métodos do pai, chama o construtor do pai com super(...) e pode sobrescrever métodos, e o TypeScript verifica que cada sobrescrita continua compatível com os tipos do pai.

class Animal {
    constructor(public name: string) {}

    speak(): string {
        return `${this.name} makes a sound`;
    }
}

class Dog extends Animal {
    constructor(name: string, public breed: string) {
        super(name); // call the parent constructor first
    }

    override speak(): string {
        return `${super.speak()}: woof`; // call the parent method
    }
}

const rex = new Dog("Rex", "beagle");
console.log(rex.speak());          // Rex makes a sound: woof
console.log(rex);                  // Dog { name: 'Rex', breed: 'beagle' }
console.log(rex instanceof Animal); // true

Isso é herança de classes do JavaScript (veja herança em JavaScript para a cadeia de protótipos por trás dela). O TypeScript acrescenta as verificações de tipo: um Dog pode ser atribuído em qualquer lugar em que um Animal é esperado, e o compilador verifica a sobrescrita e a chamada a super.

Sobrescrevendo métodos

Um método da subclasse com o mesmo nome substitui o do pai. O tipo dele precisa poder ser atribuído ao do pai: parâmetros iguais ou compatíveis, tipo de retorno igual ou mais estreito. Senão, qualquer código que guarda um Animal poderia chamar o método com argumentos que a subclasse não consegue tratar.

class Formatter {
    format(value: number): string {
        return value.toString();
    }
}

class CurrencyFormatter extends Formatter {
    // Compatible: accepts more (number | bigint) and returns the same type.
    override format(value: number | bigint): string {
        return `$${value.toLocaleString("en-US")}`;
    }
}

const formatters: Formatter[] = [new Formatter(), new CurrencyFormatter()];
for (const f of formatters) console.log(f.format(1234567));
// 1234567
// $1,234,567

Trocar o parâmetro por value: string geraria o erro TS2416: Property 'format' in type 'CurrencyFormatter' is not assignable to the same property in base type 'Formatter'. O loop mostra o porquê: ele chama format com um número em cada elemento, sem saber qual subclasse tem.

Há uma brecha. Os parâmetros de métodos são comparados de forma bivariante, então uma sobrescrita que aceita um tipo mais estreito, como format(value: 1 | 2), compila, mesmo que o loop ainda possa passar 1234567 para ela. Os tipos de retorno são verificados de forma estrita: retornar number em vez de string gera TS2416.

A palavra-chave override e o noImplicitOverride

O override diz "este membro substitui um da classe base", e o compilador cobra isso. Se a base não tem esse membro (um erro de digitação, ou um método que alguém renomeou no pai), é um erro:

// This does not compile: the parent has no method called 'speek'.
class Animal {
    speak(): string {
        return "...";
    }
}

class Cat extends Animal {
    override speek(): string {
        return "meow";
    }
}

console.log(new Cat().speak());

index.ts(9,14): error TS4117: This member cannot have an 'override' modifier because it is not declared in the base class 'Animal'. Did you mean 'speak'?

Sem o override, esse erro de digitação compila e speak() retorna "..." em silêncio. A palavra-chave só ajuda onde é escrita, então ligue o noImplicitOverride no tsconfig.json. Assim, todo método que sobrescreve um membro da base precisa dizer isso, e um speak() simples em uma subclasse gera o erro TS4114 (This member must have an 'override' modifier because it overrides a member in the base class 'Animal').

{
    "compilerOptions": {
        "strict": true,
        "noImplicitOverride": true
    }
}

O noImplicitOverride não faz parte do strict; você precisa adicioná-lo. O override é apagado do JavaScript compilado.

Membros protected em subclasses

Membros private do pai são invisíveis na subclasse. Membros protected são visíveis, e esse é o motivo de o protected existir: ele é a API que uma classe pai oferece às filhas.

class Counter {
    protected count = 0;
    private log: string[] = [];

    increment(): void {
        this.count++;
        this.log.push(`now ${this.count}`);
    }
}

class StepCounter extends Counter {
    constructor(private step: number) {
        super();
    }

    override increment(): void {
        this.count += this.step - 1; // protected: allowed
        super.increment();
        // this.log is private to Counter: a compile error here
    }

    get value(): number {
        return this.count;
    }
}

const c = new StepCounter(5);
c.increment();
c.increment();
console.log(c.value); // 10

Veja modificadores de acesso para as regras completas, incluindo por que nem private nem protected são aplicados em tempo de execução.

Redeclarando um campo com um tipo mais estreito

Uma subclasse muitas vezes sabe que um campo guarda algo mais específico do que o pai diz. Redeclará-lo como pet: Dog tem um efeito em tempo de execução com os class fields modernos: o campo da subclasse é inicializado com undefined depois que super() retorna, apagando o que o construtor do pai guardou. A menos que o construtor da subclasse o atribua de novo, o TypeScript aponta isso como TS2612 (Property 'pet' will overwrite the base property in 'Home'). Use declare para mudar só o tipo:

class Animal {
    name = "pet";
}
class Dog extends Animal {
    bark(): string {
        return "woof";
    }
}

class Home {
    pet: Animal;
    constructor(pet: Animal) {
        this.pet = pet;
    }
}

class Kennel extends Home {
    declare pet: Dog; // type only: no field is emitted

    constructor(dog: Dog) {
        super(dog);
    }
}

console.log(new Kennel(new Dog()).pet.bark()); // woof

O declare não gera nada, então o valor definido pelo construtor de Home sobrevive. O construtor que só aceita um Dog é o que torna verdadeiro o tipo mais estreito.

implements vs extends

As duas palavras-chave respondem a perguntas diferentes, e uma classe pode usar as duas.

interface Serializable {
    serialize(): string;
}

class Entity {
    constructor(readonly id: number) {}
}

class User extends Entity implements Serializable {
    constructor(id: number, readonly email: string) {
        super(id);
    }

    serialize(): string {
        return JSON.stringify({ id: this.id, email: this.email });
    }
}

const u = new User(1, "ada@example.com");
console.log(u.serialize()); // {"id":1,"email":"ada@example.com"}

Uma classe só pode estender uma classe (TS1174: Classes can only extend a single class). Para combinar comportamento de vários lugares, implemente várias interfaces e compartilhe código por composição (um campo que guarda um objeto auxiliar) ou por mixins.

Mixins

Um mixin é uma função que recebe uma classe e retorna uma subclasse dela. Ele dá uma forma de herança múltipla que passa na verificação de tipos:

type Constructor<T = {}> = new (...args: any[]) => T;

function Timestamped<TBase extends Constructor>(Base: TBase) {
    return class extends Base {
        createdAt = new Date("2024-03-15T10:30:00Z");
    };
}

function Tagged<TBase extends Constructor>(Base: TBase) {
    return class extends Base {
        tags: string[] = [];
        tag(t: string): this {
            this.tags.push(t);
            return this;
        }
    };
}

class Note {
    constructor(public text: string) {}
}

const TaggedNote = Tagged(Timestamped(Note));
const n = new TaggedNote("buy milk").tag("home");
console.log(n.text, n.tags, n.createdAt.toISOString());
// buy milk [ 'home' ] 2024-03-15T10:30:00.000Z

O any[] em Constructor é obrigatório: o TypeScript só aceita como base de mixin uma classe cujo construtor recebe um único rest parameter do tipo any[]. Mixins funcionam, mas deixam os tipos e os stack traces mais difíceis de ler, então tente composição primeiro.

Erros comuns

• Chamar um método sobrescrevível a partir do construtor da base. O construtor da base roda antes de os campos da subclasse serem inicializados, então uma sobrescrita que lê this.items vê undefined, e uma chamada como this.items.push(x) lança um TypeError em tempo de execução. O TypeScript não pega isso.
• Esquecer o super(...) ou chamá-lo tarde. Erros TS2377 e TS17009; o pai precisa montar o objeto antes que a subclasse use o this.
• Redeclarar um campo do pai sem declare. O campo da subclasse o reinicia para undefined.
• Hierarquias profundas. Cada nível acopla a filha aos detalhes internos do pai. Dois níveis costumam bastar; além disso, prefira composição ou interfaces.