Modyfikatory dostępu w TypeScript: public, private, protected

TypeScript ma trzy modyfikatory dostępu dla składowych klas: public (domyślny), protected i private. Określają, gdzie można użyć składowej, a kompilator zgłasza każdy dostęp z niewłaściwego miejsca.

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);

Ostatnia linia to błąd kompilacji, ale spójrz, co wypisała, gdy mimo to została uruchomiona: 123-45-6789. To najważniejszy fakt na tej stronie, a sekcja o private go wyjaśnia.

Na co pozwala każdy modyfikator

Modyfikatory działają na polach, metodach, getterach i setterach, konstruktorach i właściwościach parametrów (constructor(private id: string)). Pisanie public jest opcjonalne i wiele projektów je pomija.

private to sprawdzenie w czasie kompilacji

TypeScript usuwa private razem z resztą typów. Skompilowana klasa ma zwykłą właściwość, więc widzi ją wszystko, co nie przechodzi przez sprawdzanie typów: wywołania ze zwykłego JavaScriptu, JSON.stringify, Object.keys, a nawet notacja nawiasowa samego TypeScriptu, dozwolona celowo jako furtka awaryjna.

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}

To wystarcza do tego, do czego służy private: żeby powiedzieć innym programistom (i edytorowi), że składowa jest szczegółem implementacji. Nie jest to granica bezpieczeństwa, a pole private trafi do logów i odpowiedzi JSON, jeśli sam go nie usuniesz.

Pola #private: egzekwowane w czasie działania

JavaScript ma własne pola prywatne, zapisywane z #. Egzekwuje je silnik: poza klasą obj.#field nie jest nawet poprawną składnią, a pole nie pojawia się w Object.keys, JSON.stringify ani console.log.

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

Napisanie s.#token poza klasą to błąd TS18013 (Property '#token' is not accessible outside class 'Session' because it has a private identifier) i w przeciwieństwie do private nie da się tego obejść także w czasie działania. Zasady działania w runtime opisuje strona pola prywatne w JavaScript.

private a #private: czego użyć

Użyj #private, gdy dane muszą pozostać prywatne w czasie działania (tokeny, stan wewnętrzny, którego użytkownicy biblioteki nie mogą ruszać) albo gdy chcesz, żeby JSON.stringify je pominął. Użyj private, gdy chodzi tylko o czyste publiczne API, gdy framework musi odczytać pole przez refleksję albo żeby dopasować się do istniejącego stylu projektu. Nie łącz ich: private #x to błąd TS18010 (An accessibility modifier cannot be used with a private identifier).

protected i podklasy

Składowa protected jest dostępna wewnątrz klasy i w każdej klasie, która ją rozszerza, ale nie na instancjach z zewnątrz.

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

Jedna reguła bywa zaskakująca. Wewnątrz Polygon możesz odczytać sides na this albo na innym obiekcie Polygon, ale nie na zwykłym Shape przekazanym jako parametr: other.sides, gdzie other: Shape, to błąd TS2446 (Property 'sides' is protected and only accessible through an instance of class 'Polygon'. This is an instance of class 'Shape'.). Podklasa może sięgać do chronionych składowych tylko tych obiektów, które należą do jej własnej gałęzi hierarchii.

Podklasa może uczynić chronioną składową publiczną, deklarując ją ponownie, ale nie może zmienić publicznej składowej w chronioną ani prywatną. Zadeklaruj ją ponownie z inicjalizatorem (public override sides = 6) albo tylko jako typ (declare public sides: number). Samo public sides: number; zostaje odrzucone z błędami TS2564 i TS2612, bo przy nowoczesnych polach klas zresetowałoby odziedziczoną wartość do undefined po powrocie z super().

readonly

readonly blokuje ponowne przypisanie po utworzeniu obiektu. Pole można ustawić w deklaracji albo w konstruktorze; każde późniejsze przypisanie to błąd 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

Widać tu dwa ograniczenia. readonly jest płytkie: tablicy nie da się podmienić, ale jej zawartość może się zmieniać (otypuj ją jako readonly string[], żeby zablokować push). Poza tym, tak jak private, znika w czasie działania, więc przypisanie odrzucone przez kompilator i tak się wykonało. Dla wartości, która nie może się zmienić w czasie działania, użyj Object.freeze albo gettera bez settera. Strona o readonly omawia Readonly<T> i tablice tylko do odczytu.

readonly łączy się z modyfikatorami dostępu: private readonly cache = new Map<string, number>() to częsty wzorzec dla pola, które jest wewnętrzne i nigdy nie jest przypisywane ponownie.

Częste błędy

• Traktowanie private jako zabezpieczenia. W czasie działania go nie ma. Dla danych, które muszą pozostać ukryte, użyj #field i nigdy nie przekazuj obiektu z sekretami prosto do JSON.stringify.
• Pisanie public wszędzie. To wartość domyślna; dodanie jej niczego nie zmienia.
• Używanie protected do wszystkiego, co „wewnętrzne”. Jeśli żadna podklasa tego nie potrzebuje, private zmniejsza publiczną powierzchnię.
• Oczekiwanie, że readonly zamrozi zagnieżdżone dane. Blokuje tylko ponowne przypisanie samej właściwości.