Modificateurs d'accès TypeScript : public, private, protected

TypeScript a trois modificateurs d'accès pour les membres de classe : public (par défaut), protected et private. Ils contrôlent où un membre peut être utilisé, et le compilateur signale tout accès depuis un endroit interdit.

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

La dernière ligne est une erreur de compilation, mais regardez ce qu'elle a affiché une fois exécutée malgré tout : 123-45-6789. C'est le fait le plus important de cette page, et la section sur private l'explique.

Ce qu'autorise chaque modificateur

Les modificateurs s'appliquent aux champs, aux méthodes, aux getters et setters, aux constructeurs et aux propriétés de paramètres (constructor(private id: string)). Écrire public est facultatif, et beaucoup de bases de code l'omettent.

private est une vérification à la compilation

TypeScript efface private avec le reste des types. La classe compilée contient une propriété ordinaire, donc tout ce qui ne passe pas par le vérificateur de types la voit : les appelants en JavaScript pur, JSON.stringify, Object.keys, et même la notation à crochets de TypeScript, autorisée comme échappatoire volontaire.

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}

Cela convient à ce pour quoi private existe : indiquer aux autres développeurs (et à votre éditeur) qu'un membre est un détail d'implémentation. Ce n'est pas une frontière de sécurité, et un champ private finira dans les logs et les réponses JSON si vous ne le retirez pas vous-même.

Les champs #private : imposés à l'exécution

JavaScript a ses propres champs privés, écrits avec #. Le moteur les impose : hors de la classe, obj.#field n'est même pas une syntaxe valide, et le champ n'apparaît ni dans Object.keys, ni dans JSON.stringify, ni dans 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

Écrire s.#token hors de la classe provoque l'erreur TS18013 (Property '#token' is not accessible outside class 'Session' because it has a private identifier), et contrairement au cas de private, il n'existe aucun contournement à l'exécution non plus. Voir champs privés en JavaScript pour les règles d'exécution.

private ou #private : lequel utiliser

Utilisez #private quand les données doivent rester privées à l'exécution (tokens, état interne auquel les utilisateurs d'une bibliothèque ne doivent pas toucher) ou quand vous voulez que JSON.stringify les ignore. Utilisez private quand le but est seulement une API publique propre, quand un framework doit lire le champ par réflexion, ou pour suivre le style existant d'une base de code. Ne combinez pas les deux : private #x provoque l'erreur TS18010 (An accessibility modifier cannot be used with a private identifier).

protected et les sous-classes

Un membre protected est disponible dans la classe et dans toute classe qui l'étend, mais pas sur les instances depuis l'extérieur.

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

Une règle surprend. Dans Polygon, vous pouvez lire sides sur this ou sur un autre Polygon, mais pas sur un simple Shape reçu en paramètre : other.sides avec other: Shape provoque l'erreur TS2446 (Property 'sides' is protected and only accessible through an instance of class 'Polygon'. This is an instance of class 'Shape'.). Une sous-classe ne peut atteindre les membres protected que des objets qui appartiennent à sa propre branche de la hiérarchie.

Une sous-classe peut rendre public un membre protected en le redéclarant, mais elle ne peut pas rendre protected ou private un membre public. Redéclarez-le avec un initialiseur (public override sides = 6) ou uniquement en tant que type (declare public sides: number). Un simple public sides: number; est refusé avec TS2564 et TS2612, car avec les champs de classe modernes il remettrait la valeur héritée à undefined après le retour de super().

readonly

readonly bloque la réassignation après la construction. Le champ peut être défini dans sa déclaration ou dans le constructeur ; toute assignation ultérieure provoque l'erreur 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

Deux limites apparaissent ici. readonly est superficiel : le tableau ne peut pas être remplacé, mais son contenu peut changer (typez-le readonly string[] pour bloquer push). Et comme private, il disparaît à l'exécution : l'assignation refusée par le compilateur s'est donc quand même exécutée. Pour une valeur qui ne doit pas changer à l'exécution, utilisez Object.freeze ou un getter sans setter. La page readonly présente Readonly<T> et les tableaux readonly.

readonly se combine avec les modificateurs d'accès : private readonly cache = new Map<string, number>() est un motif courant pour un champ interne jamais réassigné.

Erreurs fréquentes

• Considérer private comme une sécurité. Il disparaît à l'exécution. Utilisez #field pour les données qui doivent rester cachées, et n'envoyez jamais un objet contenant des secrets directement à JSON.stringify.
• Écrire public partout. C'est la valeur par défaut ; l'ajouter ne change rien.
• Utiliser protected pour tout ce qui est « interne ». Si aucune sous-classe n'en a besoin, private garde la surface plus réduite.
• Attendre de readonly qu'il gèle les données imbriquées. Il empêche seulement la réassignation de la propriété elle-même.