01 · Problem
Wofür braucht man das?
Mehrere orthogonale Fähigkeiten sollen in einer Klasse zusammenkommen, obwohl TypeScript nur eine Basisklasse erlaubt.
02 · Denkmodell
Das mentale Modell
Ein Mixin ist eine Transformation von Basisklasse zu erweiterter Basisklasse. Config-Schemas werden zusammengeführt, Konflikte vor der Instanziierung entschieden.
Kombiniert Instanzfelder und Prototypmethoden mit validierten Konfigurationsdefaults. Namenskollisionen werden abgelehnt. Native private Felder lassen sich nicht in eine fremde Instanz verpflanzen.
03 · Kontrollfluss
Was passiert in welcher Reihenfolge?
- Mixin-Verträge und Config-Schemas einsammeln.
- Namens- und Typkonflikte vor der Klassenerzeugung erkennen.
- Defaults in eine neue Config kopieren, vollständig validieren und erst dann einfrieren.
- Prototype-Descriptors oder standardmäßige Class-Mixin-Ketten anwenden.
04 · Bauteile
Die entscheidenden Verträge
ConfigProperty / InterfaceMethodDeklariert Konfigurationsmetadaten und Methodenverträge.createClassKombiniert Felder und Prototypdeskriptoren mit Kollisionsprüfung.05 · Selbst bauen
Selbst implementieren
Bevorzuge TypeScript-Class-Mixins; sie erhalten Methoden und Typinformation ohne Runtime-Reflection.
- Definiere ein gemeinsames Constructor-Generic.
- Jedes Mixin gibt eine Unterklasse der erhaltenen Basis zurück.
- Komponiere Mixins explizit und behandle Config über normale Konstruktorparameter.
type Constructor<T = object> = new (...args: any[]) => T;
const WithLogging = <B extends Constructor>(Base: B) =>
class extends Base {
log(message: string) { console.log(message); }
};
const WithId = <B extends Constructor>(Base: B) =>
class extends Base { readonly id = crypto.randomUUID(); };
class Empty {}
class Service extends WithLogging(WithId(Empty)) {}06 · Verifizieren
Was solltest du testen?
- Komponierte Instanzen besitzen Methoden und Felder aller Mixins.
- Konfliktstrategie für gleiche Methodennamen ist festgelegt und getestet.
- Config-Defaults, ungültige Typen und unveränderte Eingabeobjekte werden geprüft.
Selbst ausprobieren
Formuliere die erste Prüfaussage als fehlschlagenden Test, implementiere die kleinste Korrektur und ergänze einen Grenzfall.
Komponierte Instanzen besitzen Methoden und Felder aller Mixins.
Ansatz vergleichen
Dein Test sollte beim gezielten Verletzen der Invariante fehlschlagen und nach der Korrektur wieder bestehen. Halte den Aufbau deterministisch und prüfe ein beobachtbares Ergebnis.
07 · Grenzen
Kompromisse und Stolperfallen
- Mixin-Ketten können komplexe Constructor- und Generic-Typen erzeugen.
- Runtime-Komposition braucht Property-Descriptors und verliert oft instanceof-Semantik.
Namenskollisionen werden abgelehnt. Native private Felder lassen sich nicht in eine fremde Instanz verpflanzen.
08 · Weiterdenken
Quellcode und verwandte Ideen
yarn tsx packages/mixin-class-factory/examples/basic.ts