TypeScript
Relación entre herencia, override y composición en TypeScript, incluyendo compatibilidad de métodos, sustitución y decisiones de diseño orientado a objetos.
class Employee {
constructor(readonly name: string) {}
describe(): string {
return this.name;
}
}
class Manager extends Employee {
constructor(
name: string,
readonly teamSize: number,
) {
super(name);
}
}Una subclase debe llamar super antes de usar this cuando define constructor.
class Manager extends Employee {
override describe(): string {
return `${this.name} manages ${this.teamSize}`;
}
}Con noImplicitOverride, el modificador es obligatorio cuando reemplazas un miembro.
Si la base renombra o elimina el método, la subclase deja de compilar.
El miembro de la subclase debe ser compatible con el contrato base.
class Base {
process(value: Animal): Animal {}
}
class Derived extends Base {
override process(value: Animal): Dog {}
}Un retorno más específico puede ser compatible. Restringir parámetros puede ser inseguro.
class Employee {
protected formatName(): string {
return this.name.toUpperCase();
}
}Permite reutilización en subclases, pero vuelve esos detalles parte del contrato de herencia.
class Base {
name = "base";
}
class Derived extends Base {
name = "derived";
}El field de subclase se inicializa según reglas runtime después de super, pudiendo reemplazar el valor base.
class AnimalHouse {
resident: Animal;
}
class DogHouse extends AnimalHouse {
declare resident: Dog;
}declare cambia el tipo sin emitir una nueva inicialización que sobrescriba el valor de la base. Debe existir una garantía runtime real.
class Base {
constructor() {
this.initialize();
}
protected initialize(): void {}
}Una subclase puede override initialize, pero sus fields aún no están inicializados cuando el constructor base lo llama. Evita este patrón.
Una subclase debe poder usarse donde se espera la base sin romper expectativas.
Peligroso:
class ReadOnlyRepository extends Repository {
override save(): never {
throw new Error("Not supported");
}
}Aunque compile bajo alguna firma, viola el contrato esperado. Separa capacidades:
interface Reader<T> {}
interface Writer<T> {}Herencia:
class CachedRepository extends ApiRepository {}Composición:
class CachedRepository implements ProductRepository {
constructor(
private readonly source: ProductRepository,
private readonly cache: ProductCache,
) {}
}La segunda puede envolver cualquier implementación y hace dependencias explícitas.
class LoggingRepository implements ProductRepository {
constructor(
private readonly inner: ProductRepository,
private readonly logger: Logger,
) {}
async save(product: Product): Promise<void> {
this.logger.info("Saving product", { id: product.id });
return this.inner.save(product);
}
}abstract class Serializer<T> {
abstract serialize(value: T): string;
abstract parse(value: string): T;
}TypeScript no tiene un modificador final general. Puedes:
Pero un consumidor con acceso al constructor runtime puede extenderla si no existe una barrera real.
En vez de subclases:
type DiscountPolicy = (
order: Order,
customer: Customer,
) => Cents;
class CheckoutService {
constructor(
private readonly discountPolicy: DiscountPolicy,
) {}
}La composición evita una jerarquía por cada estrategia.
¿Por qué una subclase que reemplaza save por un método que siempre lanza puede ser un mal diseño aunque compile?
Porque deja de poder sustituir a la clase base según su contrato observable: los consumidores esperan que guardar sea una operación soportada.
Static, private constructors y factories modela creación controlada y miembros del lado constructor.