TypeScript
Composición de comportamiento mediante mixins y clases genéricas, con restricciones de constructor y límites del patrón dentro del modelo de clases.
Un es una función que recibe una clase base y retorna una subclase con capacidades adicionales.
type Constructor<T = object> = abstract new (
...args: any[]
) => T;function Timestamped<TBase extends Constructor>(Base: TBase) {
return class extends Base {
readonly createdAt = new Date();
};
}class Entity {
constructor(readonly id: string) {}
}
class Product extends Timestamped(Entity) {
constructor(
id: string,
readonly name: string,
) {
super(id);
}
}La instancia combina miembros de Entity y Timestamped.
type Positionable = Constructor<{
x: number;
y: number;
}>;
function Movable<TBase extends Positionable>(Base: TBase) {
return class extends Base {
move(dx: number, dy: number) {
this.x += dx;
this.y += dy;
}
};
}El mixin solo acepta bases con x e y.
type AbstractConstructor<T = object> = abstract new (
...args: any[]
) => T;La subclase heredada conserva normalmente los parámetros del constructor base mediante el tipo retornado, pero mixins complejos pueden requerir aliases y assertions.
En patrones compatibles con la emisión de TypeScript, una mixin class suele declarar constructor con un único rest parameter any[] y pasarlo a super.
function Activatable<TBase extends Constructor>(Base: TBase) {
return class extends Base {
isActive = false;
constructor(...args: any[]) {
super(...args);
}
activate() {
this.isActive = true;
}
};
}any[] aquí refleja una limitación del patrón; encapsúlalo dentro del mixin.
const AuditedEntity = Activatable(Timestamped(Entity));El orden afecta:
Si dos mixins añaden el mismo método, el último de la cadena puede sobrescribir runtime, mientras los tipos pueden producir una forma que oculta la intención.
Define nombres y contratos compatibles o evita la composición.
Un mixin no puede declarar propiedades privadas de TypeScript de la misma manera que una jerarquía comparte protected members. #private pertenece a cada clase que lo declara y puede usarse internamente sin colisión de nombres.
Mixin:
class SearchableProduct extends Searchable(Product) {}Composición:
class ProductController {
constructor(
private readonly search: ProductSearch,
) {}
}La composición explícita suele ser más fácil de probar y razonar. Mixins aportan cuando la API necesita realmente instancias con métodos combinados.
class Collection<TItem> {
constructor(
private readonly items: TItem[] = [],
) {}
map<TOutput>(
transform: (item: TItem) => TOutput,
): Collection<TOutput> {
return new Collection(this.items.map(transform));
}
}Patrón avanzado:
abstract class Builder<TSelf extends Builder<TSelf>> {
withName(name: string): TSelf {
return this as unknown as TSelf;
}
}Puede preservar el tipo derivado en APIs fluent, pero this polymorphic suele ser más simple:
class Builder {
withName(name: string): this {
return this;
}
}class QueryBuilder {
where(condition: string): this {
return this;
}
}Subclases conservan su tipo al encadenar.
class Collection<T> {
static from<TItem>(items: readonly TItem[]): Collection<TItem> {
return new Collection([...items]);
}
}interface Disposable {
dispose(): void;
}
function DisposableResource<TBase extends Constructor>(Base: TBase) {
return class extends Base implements Disposable {
#disposed = false;
dispose(): void {
this.#disposed = true;
}
protected assertActive(): void {
if (this.#disposed) {
throw new Error("Resource is disposed");
}
}
};
}any[] fuera del helper.¿Por qué Timestamped(Activatable(Base)) puede comportarse distinto a Activatable(Timestamped(Base))?
Porque cada mixin crea una capa distinta de herencia; el orden cambia inicialización, overrides y qué clase queda más cerca de la instancia.
Módulos y type-only imports inicia el bloque de declaraciones, resolución e interoperabilidad.