TypeScript Zugriffsmodifikatoren: public, private, protected

TypeScript hat drei Zugriffsmodifikatoren für Klassenmember: public (der Standard), protected und private. Sie steuern, wo ein Member verwendet werden darf, und der Compiler meldet jeden Zugriff von der falschen Stelle.

class Employee {
    public name: string;          // anywhere (public is the default)
    protected salary: number;     // this class and subclasses
    private ssn: string;          // this class only

    constructor(name: string, salary: number, ssn: string) {
        this.name = name;
        this.salary = salary;
        this.ssn = ssn;
    }

    maskedSsn(): string {
        return "***-**-" + this.ssn.slice(-4); // fine: inside the class
    }
}

const e = new Employee("Ada", 5000, "123-45-6789");
console.log(e.name, e.maskedSsn()); // Ada ***-**-6789

// @ts-expect-error: Property 'ssn' is private and only accessible within class 'Employee'.
console.log(e.ssn);

Die letzte Zeile ist ein Compilerfehler, aber sieh dir an, was sie ausgegeben hat, als sie trotzdem lief: 123-45-6789. Das ist die wichtigste Tatsache auf dieser Seite, und der Abschnitt zu private erklärt sie.

Was jeder Modifikator erlaubt

Die Modifikatoren wirken auf Felder, Methoden, Getter und Setter, Konstruktoren und Parameter Properties (constructor(private id: string)). public zu schreiben ist optional, und viele Codebasen lassen es weg.

private ist eine Prüfung beim Kompilieren

TypeScript entfernt private zusammen mit den übrigen Typen. Die kompilierte Klasse hat eine gewöhnliche Eigenschaft, also sieht alles sie, was nicht durch die Typprüfung geht: Aufrufer in reinem JavaScript, JSON.stringify, Object.keys und sogar die eckigen Klammern von TypeScript selbst, die als bewusster Notausgang erlaubt sind.

class Session {
    private token = "abc123";
    userId = 7;
}

const s = new Session();
console.log(s["token"]);           // abc123: bracket access skips the check
console.log(Object.keys(s));       // [ 'token', 'userId' ]
console.log(JSON.stringify(s));    // {"token":"abc123","userId":7}

Für den Zweck von private ist das in Ordnung: anderen Entwicklern (und deinem Editor) mitzuteilen, dass ein Member ein Implementierungsdetail ist. Es ist keine Sicherheitsgrenze, und ein private Feld landet in Logs und JSON-Antworten, wenn du es nicht selbst entfernst.

#private-Felder: zur Laufzeit durchgesetzt

JavaScript hat eigene private Felder, geschrieben mit #. Die Engine setzt sie durch: Außerhalb der Klasse ist obj.#field nicht einmal gültige Syntax, und das Feld taucht weder in Object.keys noch in JSON.stringify oder console.log auf.

class Session {
    #token = "abc123";
    userId = 7;

    constructor(token: string) {
        this.#token = token;
    }

    matches(t: string): boolean {
        return this.#token === t;
    }

    static isSession(x: object): boolean {
        return #token in x; // brand check: was x made by this class?
    }
}

const s = new Session("xyz");
console.log(s.matches("xyz"));     // true
console.log(Object.keys(s));       // [ 'userId' ]
console.log(JSON.stringify(s));    // {"userId":7}
console.log(s);                    // Session { userId: 7 }
console.log(Session.isSession(s), Session.isSession({ userId: 7 })); // true false

s.#token außerhalb der Klasse zu schreiben ist der Fehler TS18013 (Property '#token' is not accessible outside class 'Session' because it has a private identifier), und anders als bei private gibt es auch zur Laufzeit keinen Weg daran vorbei. Die Laufzeitregeln stehen unter private Felder in JavaScript.

private vs #private: was verwenden

Nimm #private, wenn die Daten zur Laufzeit privat bleiben müssen (Tokens, interner Zustand, den Nutzer einer Bibliothek nicht anfassen dürfen) oder wenn JSON.stringify sie auslassen soll. Nimm private, wenn es nur um eine saubere öffentliche API geht, wenn ein Framework das Feld per Reflection lesen muss oder um zum bestehenden Stil einer Codebasis zu passen. Kombiniere sie nicht: private #x ist der Fehler TS18010 (An accessibility modifier cannot be used with a private identifier).

protected und Unterklassen

Ein protected Member ist in der Klasse und in jeder Klasse verfügbar, die sie erweitert, aber nicht auf Instanzen von außen.

class Shape {
    protected sides: number;

    constructor(sides: number) {
        this.sides = sides;
    }
}

class Polygon extends Shape {
    describe(): string {
        return `${this.sides} sides`; // fine: subclass
    }
}

const hex = new Polygon(6);
console.log(hex.describe()); // 6 sides

// @ts-expect-error: Property 'sides' is protected and only accessible within class 'Shape' and its subclasses.
console.log(hex.sides); // 6: like private, protected is not enforced at runtime

Eine Regel überrascht viele. In Polygon kannst du sides auf this oder auf einem anderen Polygon lesen, aber nicht auf einem einfachen Shape, das als Parameter übergeben wird: other.sides mit other: Shape ist der Fehler TS2446 (Property 'sides' is protected and only accessible through an instance of class 'Polygon'. This is an instance of class 'Shape'.). Eine Unterklasse darf nur die protected Member von Objekten erreichen, die zu ihrem eigenen Zweig der Hierarchie gehören.

Eine Unterklasse kann einen protected Member durch erneute Deklaration öffentlich machen, aber keinen öffentlichen Member zu protected oder private machen. Deklariere ihn mit Initialisierer neu (public override sides = 6) oder nur als Typ (declare public sides: number). Ein nacktes public sides: number; wird mit TS2564 und TS2612 abgelehnt, weil es mit modernen Klassenfeldern den geerbten Wert nach dem Ende von super() auf undefined zurücksetzen würde.

readonly

readonly verhindert die Neuzuweisung nach der Konstruktion. Das Feld kann in seiner Deklaration oder im Konstruktor gesetzt werden; jede spätere Zuweisung ist der Fehler TS2540.

class Order {
    readonly id: string;
    readonly items: string[] = [];

    constructor(id: string) {
        this.id = id; // allowed: inside the constructor
    }
}

const order = new Order("A-17");
order.items.push("book"); // allowed: readonly is shallow
console.log(order);       // Order { id: 'A-17', items: [ 'book' ] }

// @ts-expect-error: Cannot assign to 'id' because it is a read-only property.
order.id = "B-1";
console.log(order.id);    // B-1: nothing stops it at runtime

Hier zeigen sich zwei Grenzen. readonly ist flach: Das Array lässt sich nicht ersetzen, aber sein Inhalt kann sich ändern (typisiere es als readonly string[], um push zu verhindern). Und wie private verschwindet es zur Laufzeit, die Zuweisung, die der Compiler abgelehnt hat, lief also trotzdem. Für einen Wert, der sich zur Laufzeit nicht ändern darf, nimm Object.freeze oder einen Getter ohne Setter. Die Seite zu readonly behandelt Readonly<T> und readonly Arrays.

readonly lässt sich mit den Zugriffsmodifikatoren kombinieren: private readonly cache = new Map<string, number>() ist ein verbreitetes Muster für ein Feld, das intern ist und nie neu zugewiesen wird.

Häufige Fehler

• private als Sicherheit behandeln. Zur Laufzeit ist es weg. Nimm #field für Daten, die verborgen bleiben müssen, und gib ein Objekt mit Geheimnissen nie direkt an JSON.stringify.
• Überall public schreiben. Es ist der Standard; es hinzuzufügen ändert nichts.
• protected für alles „Interne“ verwenden. Braucht keine Unterklasse den Member, hält private die Oberfläche kleiner.
• Erwarten, dass readonly verschachtelte Daten einfriert. Es verhindert nur die Neuzuweisung der Eigenschaft selbst.