Modificadores de acceso en TypeScript: public, private y protected

TypeScript tiene tres modificadores de acceso para los miembros de una clase: public (el valor por defecto), protected y private. Controlan dónde se puede usar un miembro, y el compilador informa de cualquier acceso desde el sitio equivocado.

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 última línea es un error de compilación, pero fíjate en lo que imprimió al ejecutarla de todos modos: 123-45-6789. Es el dato más importante de esta página, y la sección sobre private lo explica.

Qué permite cada modificador

Los modificadores funcionan con campos, métodos, getters y setters, constructores y parameter properties (constructor(private id: string)). Escribir public es opcional, y muchos proyectos lo omiten.

private es una comprobación en tiempo de compilación

TypeScript borra private junto con el resto de los tipos. La clase compilada tiene una propiedad normal, así que todo lo que no pasa por el comprobador de tipos la ve: quien llama desde JavaScript normal, JSON.stringify, Object.keys e incluso la notación con corchetes del propio TypeScript, que se permite como escapatoria deliberada.

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}

Eso está bien para lo que sirve private: decir a otros desarrolladores (y a tu editor) que un miembro es un detalle de implementación. No es una barrera de seguridad, y un campo private acabará en los logs y en las respuestas JSON salvo que lo quites tú.

Campos #private: se aplican en tiempo de ejecución

JavaScript tiene sus propios campos privados, escritos con #. El motor los hace cumplir: fuera de la clase, obj.#field ni siquiera es sintaxis válida, y el campo no aparece en Object.keys, JSON.stringify ni 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

Escribir s.#token fuera de la clase es el error TS18013 (Property '#token' is not accessible outside class 'Session' because it has a private identifier), y a diferencia del caso de private, tampoco hay forma de saltárselo en tiempo de ejecución. Consulta campos privados en JavaScript para las reglas en tiempo de ejecución.

private frente a #private: cuál usar

Usa #private cuando los datos deban seguir siendo privados en tiempo de ejecución (tokens, estado interno que los usuarios de una librería no deben tocar) o cuando quieras que JSON.stringify los omita. Usa private cuando el objetivo sea solo una API pública limpia, cuando un framework necesite leer el campo por reflexión o para seguir el estilo existente del proyecto. No los combines: private #x es el error TS18010 (An accessibility modifier cannot be used with a private identifier).

protected y las subclases

Un miembro protected está disponible dentro de la clase y en cualquier clase que la extienda, pero no en instancias desde fuera.

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

Hay una regla que sorprende. Dentro de Polygon, puedes leer sides sobre this o sobre otro Polygon, pero no sobre un Shape cualquiera recibido como parámetro: other.sides con other: Shape es el error TS2446 (Property 'sides' is protected and only accessible through an instance of class 'Polygon'. This is an instance of class 'Shape'.). Una subclase solo puede acceder a miembros protegidos de objetos que pertenecen a su propia rama de la jerarquía.

Una subclase puede hacer público un miembro protegido volviendo a declararlo, pero no puede hacer protegido o privado un miembro público. Vuelve a declararlo con un inicializador (public override sides = 6) o solo como tipo (declare public sides: number). Un simple public sides: number; se rechaza con TS2564 y TS2612, porque con los campos de clase modernos restablecería el valor heredado a undefined después de que super() termine.

readonly

readonly impide reasignar después de la construcción. El campo se puede asignar en su declaración o en el constructor; cualquier asignación posterior es el error 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

Aquí se ven dos límites. readonly es superficial: el array no se puede sustituir, pero su contenido puede cambiar (tipalo como readonly string[] para impedir push). Y, como private, desaparece en tiempo de ejecución, así que la asignación que rechazó el compilador se ejecutó igualmente. Para un valor que no debe cambiar en tiempo de ejecución, usa Object.freeze o un getter sin setter. La página de readonly explica Readonly<T> y los arrays readonly.

readonly se combina con los modificadores de acceso: private readonly cache = new Map<string, number>() es un patrón habitual para un campo interno que nunca se reasigna.

Errores habituales

• Tratar private como seguridad. Desaparece en tiempo de ejecución. Usa #field para datos que deben quedar ocultos, y nunca pases directamente a JSON.stringify un objeto con secretos.
• Escribir public en todas partes. Es el valor por defecto; añadirlo no cambia nada.
• Usar protected para todo lo «interno». Si ninguna subclase lo necesita, private mantiene más pequeña la superficie.
• Esperar que readonly congele los datos anidados. Solo impide reasignar la propia propiedad.