Pola prywatne w JavaScript: składnia # w klasach

Problem z podkreśleniami

Przez lata JavaScript nie miał pól prywatnych. Konwencja polegała na dodaniu podkreślenia przed nazwą właściwości i liczeniu na to, że wszyscy to uszanują:

class Counter {
    constructor() {
        this._count = 0;
    }
    increment() {
        this._count++;
    }
}

const c = new Counter();
c.increment();
console.log(c._count);   // 1 - nothing stops this
c._count = 999;          // or this
console.log(c._count);   // 999

_count wygląda na prywatne, ale takie nie jest. Każdy kod wywołujący może je odczytać, zapisać albo usunąć. Podkreślenie to uprzejma kartka na drzwiach, a same drzwi są szeroko otwarte.

Nowoczesny JavaScript rozwiązał to prawdziwymi polami prywatnymi oznaczanymi znakiem #.

# sprawia, że pole jest prywatne

Poprzedź nazwę pola znakiem # w deklaracji i w każdym miejscu, gdzie się do niego odwołujesz:

class Counter {
    #count = 0;

    increment() {
        this.#count++;
    }

    get value() {
        return this.#count;
    }
}

const c = new Counter();
c.increment();
c.increment();
console.log(c.value);    // 2

Wewnątrz klasy this.#count działa normalnie. Z zewnątrz po prostu nie istnieje:

class Counter {
    #count = 0;
    increment() { this.#count++; }
}

const c = new Counter();
// console.log(c.#count);   // SyntaxError at parse time
console.log(c["#count"]);   // undefined - not the same property

# jest dosłownie częścią nazwy pola. To nie jest słowo kluczowe typu private znane z innych języków, tylko znak, którego parser używa do wyszukania osobnego, chronionego miejsca w obiekcie. Dlatego błąd pojawia się już podczas parsowania, zanim kod w ogóle się uruchomi.

Prywatne metody i gettery

Nie tylko pola można oznaczyć jako prywatne. Metody, gettery i settery też przyjmują prefiks #:

class BankAccount {
    #balance = 0;

    deposit(amount) {
        this.#assertPositive(amount);
        this.#balance += amount;
    }

    get balance() {
        return this.#balance;
    }

    #assertPositive(n) {
        if (n <= 0) throw new Error("Amount must be positive");
    }
}

const acc = new BankAccount();
acc.deposit(100);
console.log(acc.balance);    // 100
// acc.#assertPositive(5);   // SyntaxError

#assertPositive to wewnętrzna funkcja pomocnicza. Nie jest częścią publicznego API, więc uczynienie jej naprawdę prywatną oznacza, że nikt przypadkiem nie wywoła jej z zewnątrz. Nikt też nie może się od niej uzależnić, dzięki czemu możesz ją później swobodnie przemianować albo usunąć.

Prywatne składowe statyczne

Składowe statyczne też mogą być prywatne. Oznaczasz je znakiem # w ten sam sposób:

class IdGenerator {
    static #nextId = 1;

    static generate() {
        return IdGenerator.#nextId++;
    }
}

console.log(IdGenerator.generate());   // 1
console.log(IdGenerator.generate());   // 2
// console.log(IdGenerator.#nextId);   // SyntaxError

Prywatne składowe statyczne należą do samej klasy, a nie do instancji. Przydają się do liczników, cache albo konfiguracji, która nie powinna wyciekać poza klasę.

Podklasy ich nie widzą

To zaskakuje osoby przychodzące z Javy lub C#. Pola prywatne w JavaScript są prywatne dla klasy, a nie prywatne dla instancji. Podklasa nie sięgnie do prywatnych pól swojej klasy nadrzędnej:

class Animal {
    #name;
    constructor(name) {
        this.#name = name;
    }
    describe() {
        return `an animal named ${this.#name}`;
    }
}

class Dog extends Animal {
    bark() {
        // return `${this.#name} says woof`;   // SyntaxError
        return `${this.describe()} says woof`;
    }
}

console.log(new Dog("Rex").bark());

W JavaScript nie ma protected. Jeśli podklasa potrzebuje danych, klasa nadrzędna musi udostępnić metodę, getter albo (rzadziej) pole nieprywatne. To celowa decyzja: prywatne naprawdę znaczy prywatne, a dziedziczenie nie robi w tym dziur.

Sprawdzanie pola prywatnego przez in

Czasem chcesz potwierdzić, że obiekt naprawdę należy do twojej klasy. To tak zwany brand check. Operator in działa z nazwami pól prywatnych wewnątrz klasy:

class Wallet {
    #balance = 0;

    static isWallet(obj) {
        return #balance in obj;
    }
}

const real = new Wallet();
const fake = { balance: 100 };

console.log(Wallet.isWallet(real));   // true
console.log(Wallet.isWallet(fake));   // false

Ponieważ tylko Wallet może tworzyć obiekty z #balance, #balance in obj jest niezawodnym testem na to, że obj to prawdziwa instancja Wallet. W niektórych przypadkach brzegowych jest to szybsze i bezpieczniejsze niż instanceof, bo pól prywatnych nie da się podrobić z zewnątrz.

Częsta pułapka: zwykłe obiekty go nie mają

Pola prywatne istnieją w instancjach utworzonych przez konstruktor klasy. Jeśli spróbujesz użyć takiego pola na obiekcie, który nie powstał przez new, dostaniesz błąd:

class Point {
    #x;
    constructor(x) { this.#x = x; }
    getX() { return this.#x; }
}

const p = new Point(5);
console.log(p.getX());       // 5

const fake = {};
// Point.prototype.getX.call(fake);   // TypeError: Cannot read private member #x

Wywołanie metody z this, które nie jest instancją Point, rzuca błąd w czasie działania. To mechanizm stojący za brand checkiem opisanym wyżej: pola prywatne są związane z konkretną klasą, która je zadeklarowała, a nie z każdym obiektem, który przypadkiem wygląda podobnie.

Kiedy sięgać po #

Domyślnie używaj pól prywatnych zawsze, gdy fragment stanu albo funkcja pomocnicza nie jest częścią publicznego API klasy. Powody:

• Swoboda refaktoryzacji. Kod wywołujący nie może zależeć od wnętrza, którego dosłownie nie widzi.
• Prawdziwa enkapsulacja. Żadnych przypadkowych odczytów, zapisów ani usunięć z zewnątrz.
• Czystsze podpowiedzi. Edytory nie proponują prywatnych składowych kodowi z zewnątrz.

Używaj publicznych właściwości, gdy coś naprawdę jest częścią interfejsu. Użyj gettera (get name()), gdy chcesz dać dostęp tylko do odczytu do pola prywatnego. Pomiń konwencję z podkreśleniem: była obejściem luki, którą język już wypełnił.

class Temperature {
    #celsius;

    constructor(celsius) {
        this.#celsius = celsius;
    }

    get celsius() { return this.#celsius; }
    get fahrenheit() { return this.#celsius * 9 / 5 + 32; }
}

const t = new Temperature(20);
console.log(t.celsius);      // 20
console.log(t.fahrenheit);   // 68
// t.celsius = 100;          // TypeError: no setter - read-only

#celsius to ukryte miejsce na dane, a celsius i fahrenheit to widoki tylko do odczytu. Kod wywołujący nie może zepsuć wewnętrznego stanu, a klasa może później swobodnie zmienić sposób przechowywania wartości.

Dalej: prototypy

Klasy to w dużej mierze lukier składniowy nad systemem prototypów JavaScript, czyli starszym i bardziej podstawowym modelem, na którym język naprawdę jest zbudowany. Zrozumienie prototypów wyjaśnia, dlaczego this zachowuje się tak, a nie inaczej, jak naprawdę działa dziedziczenie i co klasa rozszerza przez extends pod spodem. O tym jest następna strona.