Maszynopis prywatne członków

JavaScript nie obsługuje zmiennych prywatnych.

function MyClass() {
    var myPrivateVar = 3;

    this.doSomething = function() {
        return myPrivateVar++;        
    }
}

W maszynopisie miałoby to być wyrażona w taki sposób:

class MyClass {

    doSomething: () => number;

    constructor() {
        var myPrivateVar = 3;

        this.doSomething = function () {
            return myPrivateVar++;
        }
    }
}

EDYTOWAĆ

Takie podejście powinno być stosowane tylko oszczędnie , gdzie jest to absolutnie konieczne. Na przykład, jeśli trzeba buforować hasło tymczasowe.

Są to koszty wykonania do korzystania z tego wzorca (w dowolnej JavaScript lub maszynopis) i powinny być stosowane tylko wtedy, gdy jest to absolutnie konieczne.

Po wsparcie dla WeakMap jest szerzej dostępna jest interesująca technika szczegółowo w przykładzie nr 3 tutaj .

Pozwala to na prywatnych danych i pozwala uniknąć kosztów wydajności przykład Jason Evans, pozwalając danych, które będą dostępne z metod prototypowych, a nie tylko metody instancji.

Połączony MDN WeakMap wykazy stron na wsparcie przeglądarka Chrome 36, Firefox 6.0, IE 11, Opera 23 oraz Safari 7.1.

let _counter = new WeakMap();
let _action = new WeakMap();
class Countdown {
  constructor(counter, action) {
    _counter.set(this, counter);
    _action.set(this, action);
  }
  decrement() {
    let counter = _counter.get(this);
    if (counter < 1) return;
    counter--;
    _counter.set(this, counter);
    if (counter === 0) {
      _action.get(this)();
    }
  }
}

Dzięki Sean Feldman za link do oficjalnej dyskusji na ten temat - patrz jego odpowiedź dla łącza.

Czytam dyskusję on powiązany, a oto podsumowanie najważniejszych punktów:

• Sugestia: Właściwości prywatnych w konstruktorze
  • problemy: Nie można uzyskać dostępu z funkcjami prototypowych
• Sugestia: metody prywatne w konstruktorze
  • Problemy: takie same jak w przypadku nieruchomości, a także utratę korzyści wydajności tworzenia funkcji raz w klasie w prototypie; zamiast tworzenia kopii funkcji dla każdej instancji
• Sugestia: dodać Gotowa do abstrakcyjnego dostępu do własności i egzekwowania widoczność
  • Problemy: Głównym napowietrznych wydajność; Maszynopis jest przeznaczony dla dużych aplikacji
• Sugestia: maszynopis już zawija definicji konstruktora i metoda prototyp w zamknięciu; umieścić prywatnych metod i właściwości tam
  • problemy z przekazaniem własności prywatnej w tym zamknięcia: stają się zmienne statyczne; nie ma jednej na przykład
  • problemy z wprowadzeniem metod prywatnych w tym zamknięcia: nie mają dostępu do thisbez jakiegoś obejścia
• Sugestia: automatycznie magiel prywatnych nazw zmiennych
  • Argumenty Licznik: to jest konwencja nazewnictwa, a nie konstrukcją języka. Magiel to sam
• Sugestia: Opisywanie prywatnych metod z@private tak minifiers że uznają, że adnotacja może skutecznie minify nazwy metody
  • Nie stwierdzono istotnych argumenty sprzeczne z tym jednym

Ogółem kontrargumenty do dodawania wsparcia widoczności emitowanego w kodzie:

• problemem jest to, że sama JavaScript nie mają modyfikatory widoczności - to nie jest problem, maszynopis w
• istnieje już ustalony wzorzec w społeczności javascript: prefiks prywatne właściwości i metody znakiem podkreślenia, który mówi „przejść na własne ryzyko”
• kiedy projektanci maszynopis, że właściwości prawdziwie prywatne i metody nie są „możliwe”, to znaczy „nie możliwe w naszych ograniczeń projektowych”, w szczególności:
  • Emitowany jest JS idiomatycznym
  • Gotowa jest minimalny
  • No dodatkowy narzut w porównaniu do normalnego JS OOP

W maszynopisie funkcje prywatne są dostępne tylko wewnątrz klasy. Lubić

I pokaże błąd podczas próby uzyskania dostępu do prywatnego członka. Oto przykład:

Uwaga: To będzie w porządku zarówno javascript i funkcji są dostępne na zewnątrz.

Zdaję sobie sprawę, że jest to starsza dyskusja, ale nadal może być przydatny do dzielenia się moje rozwiązanie problemu zmiennych rzekomo prywatnych i metod w maszynopisie „wycieka” na zewnątrz do publicznego interfejsu klasy skompilowany JavaScript.

Dla mnie ten problem jest czysto kosmetyczny, czyli wszystko o wizualnego bałaganu gdy zmienna instancji jest oglądany w DevTools. Moja poprawka jest do grupy prywatnych deklaracji razem wewnątrz innej klasy, która jest następnie instancja w głównej klasie i przypisany do private(ale nadal publicznie widoczny w JS) zmiennej o nazwie typu __(podwójnego podkreślenia).

Przykład:

class Privates {
    readonly DEFAULT_MULTIPLIER = 2;
    foo: number;
    bar: number;

    someMethod = (multiplier: number = this.DEFAULT_MULTIPLIER) => {
        return multiplier * (this.foo + this.bar);
    }

    private _class: MyClass;

    constructor(_class: MyClass) {
        this._class = _class;
    }
}

export class MyClass {
    private __: Privates = new Privates(this);

    constructor(foo: number, bar: number, baz: number) {
        // assign private property values...
        this.__.foo = foo;
        this.__.bar = bar;

        // assign public property values...
        this.baz = baz;
    }

    baz: number;

    print = () => {
        console.log(`foo=${this.__.foo}, bar=${this.__.bar}`);
        console.log(`someMethod returns ${this.__.someMethod()}`);
    }
}

let myClass = new MyClass(1, 2, 3);

Gdy myClassinstancja jest postrzegana w DevTools, zamiast widzieć wszystkie swoje „prywatne” członków wymieszane z iście te publiczne (które mogą się bardzo wizualnie bałagan w prawidłowo refactored kodu rzeczywistych) widać je starannie pogrupowane wewnątrz zwiniętym __nieruchomości:

Wiele osób twierdzi, nie jest to możliwe ze względu na ograniczenia w JavaScript. Powiedziałbym, że to ograniczenia w twórczości programistom JavaScriptu.

Zajmuję się bibliotekę teraz, że pozwala prywatne i chronione dziedzicznych członków klas, a także interfejsy itp nazywa ClassJS. Sprawdź tutaj na GitHub .