Zugriffsmodifizierer in TypeScript
Zugriffsmodifizierer
~14 Min. Lesezeit Zuletzt aktualisiert am 8. August 2026
Bisher waren ALLE Eigenschaften unserer Klassen von ÜBERALL im Code lesbar und veränderbar. Zugriffsmodifizierer erlauben es, den internen Zustand einer Klasse vor unkontrolliertem Zugriff von außen zu schützen – ein Kernprinzip objektorientierter Programmierung namens "Encapsulation" (Kapselung).
public, private, protected
export class Bibliothek {
private bestand: Buch[]; // NUR innerhalb dieser Klasse lesbar/schreibbar
public name: string; // von ÜBERALL zugänglich (Standard, wenn nichts angegeben ist)
constructor(name: string, startBestand: Buch[]) {
this.name = name;
this.bestand = startBestand;
}
public buchAnzahl(): number {
return this.bestand.length; // ✓ erlaubt - innerhalb der Klasse
}
}
const bibliothek = new Bibliothek('Stadtbibliothek', []);
bibliothek.name; // ✓ erlaubt - public
bibliothek.bestand; // ✗ Fehler - private, nicht von außen zugänglich
bibliothek.buchAnzahl(); // ✓ erlaubt - public Methodepublic ist der STANDARD – jede Eigenschaft/Methode OHNE explizite Angabe ist automatisch public. private ist das genaue Gegenteil: NUR Code INNERHALB derselben Klasse darf darauf zugreifen, selbst abgeleitete Klassen NICHT.
protected: sichtbar für abgeleitete Klassen
export class Medium {
protected verlaengerungen: number = 0; // sichtbar für Medium UND alle abgeleiteten Klassen
protected pruefeVerfuegbarkeit(): boolean {
return this.status === 'verfuegbar';
}
}
export class Buch extends Medium {
leiheAusMitVerlaengerung(): void {
if (this.pruefeVerfuegbarkeit()) { // ✓ erlaubt - protected, Buch ERBT von Medium
this.verlaengerungen++; // ✓ erlaubt
}
}
}
const buch = new Buch(/* ... */);
buch.verlaengerungen; // ✗ Fehler - protected, NICHT von außerhalb der Klassenhierarchieprotected ist der "Mittelweg" zwischen public und private: sichtbar für die Klasse SELBST und ALLE Klassen, die davon ERBEN, aber NICHT für Code außerhalb dieser Hierarchie.
Praxis: bestand in Bibliothek privatisieren
Erinnern Sie sich an Bibliothek aus Kapitel 12? bestand war public – JEDER Code konnte das Array direkt manipulieren (bibliothek.bestand.push(...)), OHNE die kontrollierten leiheAus-Methoden zu durchlaufen. Wir schützen das jetzt:
import { Buch } from '../models/Buch.js';
export class Bibliothek {
private bestand: Buch[];
constructor(startBestand: Buch[]) {
this.bestand = startBestand;
}
public buchAnzahl(): number {
return this.bestand.length;
}
public findeNachTitel(titel: string): Buch | undefined {
return this.bestand.find((buch) => buch.titel === titel);
}
public leiheAus(isbn: string): boolean {
const buch = this.bestand.find((b) => b.isbn === isbn);
if (!buch || buch.status !== 'verfuegbar') {
return false;
}
buch.status = 'ausgeliehen';
return true;
}
public gibZurueck(isbn: string): boolean {
const buch = this.bestand.find((b) => b.isbn === isbn);
if (!buch || buch.status !== 'ausgeliehen') {
return false;
}
buch.status = 'verfuegbar';
return true;
}
public alleBuecher(): readonly Buch[] {
return this.bestand; // gibt eine LESBARE Sicht zurück, kein direkter Schreibzugriff
}
}alleBuecher(): readonly Buch[] kombiniert Kapitel 11 (readonly Arrays) mit diesem Kapitel: von außen kann man den Bestand LESEN (z. B. mit .map(), .filter() iterieren), aber NICHT direkt verändern – jede Änderung MUSS über leiheAus/gibZurueck laufen, die den Status korrekt und kontrolliert verwalten.
Achtung: Zugriffsmodifizierer sind eine REINE Kompilierzeit-Prüfung – anders als in Sprachen wie Java verschwinden private/protected beim Kompilieren zu JavaScript VOLLSTÄNDIG (siehe Kapitel 1: Typannotationen existieren nur zur Entwicklungszeit). Zur Laufzeit ist bibliothek.bestand technisch trotzdem über JavaScript-eigene Tricks erreichbar – für ECHTE Laufzeit-Kapselung gibt es private Klassenfelder mit #-Präfix (natives JavaScript-Feature, nicht TypeScript-spezifisch), hier aus Gründen der Übersichtlichkeit nicht vertieft.
Tipp: Faustregel: Eigenschaften standardmäßig private machen, NUR bei tatsächlichem Bedarf von außen (oder für abgeleitete Klassen) auf public/protected lockern. Diese "restriktiv zuerst"-Denkweise verhindert, dass interner Zustand versehentlich von Code abhängig wird, den Sie später nicht mehr risikolos ändern können.