Modificatori di accesso in TypeScript: public, private, protected

TypeScript ha tre modificatori di accesso per i membri di una classe: public (il predefinito), protected e private. Controllano dove si può usare un membro, e il compilatore segnala qualsiasi accesso dal posto sbagliato.

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

L'ultima riga è un errore di compilazione, ma guarda cosa ha stampato eseguendola comunque: 123-45-6789. È il fatto più importante di questa pagina, e la sezione su private lo spiega.

Cosa consente ogni modificatore

I modificatori funzionano su campi, metodi, getter e setter, costruttori e parameter property (constructor(private id: string)). Scrivere public è facoltativo, e molti codebase lo omettono.

private è un controllo in compilazione

TypeScript cancella private insieme al resto dei tipi. La classe compilata ha una proprietà normale, quindi tutto ciò che non passa dal type checker la vede: chiamanti in JavaScript semplice, JSON.stringify, Object.keys e perfino la notazione con parentesi quadre di TypeScript stesso, permessa di proposito come via di fuga.

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}

Va bene per lo scopo di private: dire agli altri sviluppatori (e al tuo editor) che un membro è un dettaglio di implementazione. Non è un confine di sicurezza, e un campo private finirà nei log e nelle risposte JSON se non lo togli tu.

Campi #private: imposti a runtime

JavaScript ha i propri campi privati, scritti con #. È il motore a imporli: fuori dalla classe, obj.#field non è nemmeno sintassi valida, e il campo non compare in Object.keys, JSON.stringify o 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

Scrivere s.#token fuori dalla classe è l'errore TS18013 (Property '#token' is not accessible outside class 'Session' because it has a private identifier), e a differenza del caso private non c'è modo di aggirarlo nemmeno a runtime. Vedi i campi privati in JavaScript per le regole a runtime.

private vs #private: quale usare

Usa #private quando i dati devono restare privati a runtime (token, stato interno che gli utenti di una libreria non devono toccare) o quando vuoi che JSON.stringify li lasci fuori. Usa private quando l'obiettivo è solo un'API pubblica pulita, quando un framework deve leggere il campo per riflessione, o per seguire lo stile esistente di un codebase. Non combinarli: private #x è l'errore TS18010 (An accessibility modifier cannot be used with a private identifier).

protected e sottoclassi

Un membro protected è disponibile dentro la classe e in qualsiasi classe che la estende, ma non sulle istanze da fuori.

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

Una regola sorprende molti. Dentro Polygon puoi leggere sides su this o su un altro Polygon, ma non su un semplice Shape passato come parametro: other.sides con other: Shape è l'errore TS2446 (Property 'sides' is protected and only accessible through an instance of class 'Polygon'. This is an instance of class 'Shape'.). Una sottoclasse può raggiungere i membri protected solo degli oggetti che appartengono al suo ramo della gerarchia.

Una sottoclasse può rendere pubblico un membro protected ridichiarandolo, ma non può rendere protected o private un membro pubblico. Ridichiaralo con un inizializzatore (public override sides = 6) o solo come tipo (declare public sides: number). Un semplice public sides: number; viene rifiutato con TS2564 e TS2612, perché con i class field moderni reimposterebbe il valore ereditato a undefined dopo il ritorno di super().

readonly

readonly impedisce la riassegnazione dopo la costruzione. Il campo si può impostare nella dichiarazione o nel costruttore; qualsiasi assegnazione successiva è l'errore 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

Qui emergono due limiti. readonly è superficiale: l'array non si può sostituire, ma il suo contenuto può cambiare (tipizzalo readonly string[] per bloccare push). E come private, sparisce a runtime, quindi l'assegnazione rifiutata dal compilatore è stata eseguita lo stesso. Per un valore che non deve cambiare a runtime, usa Object.freeze o un getter senza setter. La pagina su readonly tratta Readonly<T> e gli array readonly.

readonly si combina con i modificatori di accesso: private readonly cache = new Map<string, number>() è un pattern comune per un campo interno che non viene mai riassegnato.

Errori comuni

• Trattare private come sicurezza. A runtime non c'è più. Usa #field per i dati che devono restare nascosti, e non passare mai un oggetto con dei segreti direttamente a JSON.stringify.
• Scrivere public ovunque. È il predefinito; aggiungerlo non cambia nulla.
• Usare protected per tutto ciò che è "interno". Se nessuna sottoclasse ne ha bisogno, private tiene la superficie più piccola.
• Aspettarsi che readonly congeli i dati annidati. Impedisce solo la riassegnazione della proprietà stessa.