Perché posso accedere ai membri privati ​​di TypeScript quando non dovrei essere in grado di farlo?

Sto esaminando l'implementazione di membri privati ​​in TypeScript e lo trovo un po 'confuso. Intellisense non consente l'accesso a membri privati, ma in JavaScript puro, è tutto lì. Questo mi fa pensare che TS non implementa correttamente i membri privati. qualche idea?

class Test{
  private member: any = "private member";
}
alert(new Test().member);

Proprio come con il controllo del tipo, la privacy dei membri viene applicata solo all'interno del compilatore.

Una proprietà privata viene implementata come una proprietà normale e il codice esterno alla classe non è autorizzato ad accedervi.

Per rendere qualcosa di veramente privato all'interno della classe, non può essere un membro della classe, sarebbe una variabile locale creata all'interno di uno scope di funzione all'interno del codice che crea l'oggetto. Ciò significherebbe che non puoi accedervi come un membro della classe, cioè utilizzando la thisparola chiave.

JavaScript supporta le variabili private.

function MyClass() {
    var myPrivateVar = 3;

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

In TypeScript questo sarebbe espresso in questo modo:

class MyClass {

    doSomething: () => number;

    constructor() {
        var myPrivateVar = 3;

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

MODIFICARE

Questo approccio dovrebbe essere usato RISPARMIANDO dove è assolutamente necessario. Ad esempio, se è necessario memorizzare temporaneamente una password nella cache.

L'uso di questo pattern comporta dei costi di prestazione (irrilevante per Javascript o Typescript) e dovrebbe essere utilizzato solo dove assolutamente necessario.

Una volta che il supporto per WeakMap è più ampiamente disponibile, c'è una tecnica interessante descritta in dettaglio nell'esempio # 3 qui .

Consente dati privati ​​ED evita i costi di prestazione dell'esempio di Jason Evans consentendo ai dati di essere accessibili da metodi prototipo invece che solo metodi di istanza.

La pagina MDN WeakMap collegata elenca il supporto del browser su Chrome 36, Firefox 6.0, IE 11, Opera 23 e 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)();
    }
  }
}

Dal momento che TypeScript 3.8 sarà rilasciato, sarai in grado di dichiarare un campo privato a cui non è possibile accedere o addirittura rilevato al di fuori della classe contenente .

class Person {
    #name: string

    constructor(name: string) {
        this.#name = name;
    }

    greet() {
        console.log(`Hello, my name is ${this.#name}!`);
    }
}

let jeremy = new Person("Jeremy Bearimy");

jeremy.#name
//     ~~~~~
// Property '#name' is not accessible outside class 'Person'
// because it has a private identifier.

I campi privati ​​iniziano con il #carattere

Tieni presente che questi campi privati ​​saranno qualcosa di diverso dai campi contrassegnati con privateparola chiave

Ref. https://devblogs.microsoft.com/typescript/announcing-typescript-3-8-beta/

Grazie a Sean Feldman per il collegamento alla discussione ufficiale su questo problema - vedere la sua risposta per il collegamento.

Ho letto la discussione a cui si è collegato ed ecco un riassunto dei punti chiave:

• Suggerimento: proprietà private nel costruttore
  • problemi: impossibile accedere dalle funzioni del prototipo
• Suggerimento: metodi privati ​​nel costruttore
  • problemi: come con le proprietà, in più si perde il vantaggio in termini di prestazioni di creare una funzione una volta per classe nel prototipo; invece crei una copia della funzione per ogni istanza
• Suggerimento: aggiungi boilerplate per astrarre l'accesso alla proprietà e rafforzare la visibilità
  • problemi: maggiore sovraccarico delle prestazioni; TypeScript è progettato per applicazioni di grandi dimensioni
• Suggerimento: TypeScript racchiude già le definizioni del metodo del costruttore e del prototipo in una chiusura; mettere metodi e proprietà privati ​​lì
  • problemi con l'inserimento di proprietà private in quella chiusura: diventano variabili statiche; non ce n'è uno per istanza
  • problemi con l'inserimento di metodi privati ​​in quella chiusura: non hanno accesso thissenza una sorta di soluzione alternativa
• Suggerimento: manipola automaticamente i nomi delle variabili private
  • controargomenti: questa è una convenzione di denominazione, non un costrutto di linguaggio. Mangialo da solo
• Suggerimento:@private annota metodi privati ​​con minificatori così che riconoscono che l'annotazione può minimizzare efficacemente i nomi dei metodi
  • Nessun argomento controverso significativo a questo

Controargomentazioni complessive per l'aggiunta del supporto di visibilità nel codice emesso:

• il problema è che JavaScript stesso non ha modificatori di visibilità - questo non è un problema di TypeScript
• esiste già un modello stabilito nella comunità JavaScript: anteporre alle proprietà e ai metodi privati ​​un carattere di sottolineatura, che dice "procedi a tuo rischio"
• quando i progettisti di TypeScript hanno affermato che proprietà e metodi veramente privati ​​non sono "possibili", intendevano "non possibili sotto i nostri vincoli di progettazione", in particolare:
  • Il JS emesso è idiomatico
  • Boilerplate è minimo
  • Nessun overhead aggiuntivo rispetto al normale JS OOP

In TypeScript le funzioni private sono accessibili solo all'interno della classe. Piace

E mostrerà un errore quando proverai ad accedere a un membro privato. Ecco l'esempio:

Nota: andrà bene con javascript ed entrambe le funzioni sono accessibili dall'esterno.

Mi rendo conto che questa è una discussione precedente, ma potrebbe essere ancora utile condividere la mia soluzione al problema delle variabili e dei metodi presumibilmente privati ​​in un TypeScript che "trapela" nell'interfaccia pubblica della classe JavaScript compilata.

Per me questo problema è puramente estetico, cioè riguarda tutto il disordine visivo quando una variabile di istanza viene visualizzata in DevTools. La mia soluzione è raggruppare le dichiarazioni private insieme all'interno di un'altra classe che viene quindi istanziata nella classe principale e assegnata a una privatevariabile (ma ancora visibile pubblicamente in JS) con un nome come __(doppio trattino basso).

Esempio:

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

Quando l' myClassistanza viene visualizzata in DevTools, invece di vedere tutti i suoi membri "privati" mescolati con quelli veramente pubblici (che possono diventare molto visivamente disordinati in codice reale correttamente refactored) li vedi raggruppati ordinatamente all'interno della __proprietà compressa :

Ecco un approccio riutilizzabile per aggiungere proprietà private appropriate:

/**
 * Implements proper private properties.
 */
export class Private<K extends object, V> {

    private propMap = new WeakMap<K, V>();

    get(obj: K): V {
        return this.propMap.get(obj)!;
    }

    set(obj: K, val: V) {
        this.propMap.set(obj, val);
    }
}

Supponiamo che tu abbia una classe Clientda qualche parte che necessita di due proprietà private:

• prop1: string
• prop2: number

Di seguito è riportato come implementarlo:

// our private properties:
interface ClientPrivate {
    prop1: string;
    prop2: number;
}

// private properties for all Client instances:
const pp = new Private<Client, ClientPrivate>();

class Client {
    constructor() {
        pp.set(this, {
            prop1: 'hello',
            prop2: 123
        });
    }

    someMethod() {
        const privateProps = pp.get(this);

        const prop1 = privateProps.prop1;
        const prop2 = privateProps.prop2;
    }
}

E se tutto ciò di cui hai bisogno è una singola proprietà privata, diventa ancora più semplice, perché non avresti bisogno di definirne alcuna ClientPrivate in quel caso.

Vale la pena notare che, per la maggior parte, la classe Privateoffre solo una firma ben leggibile, mentre l'uso diretto di WeakMapnon lo fa.