Pourquoi puis-je accéder aux membres privés TypeScript alors que je ne devrais pas pouvoir le faire?

Je regarde l'implémentation de membres privés dans TypeScript, et je trouve cela un peu déroutant. Intellisense ne permet pas d'accéder aux membres privés, mais en JavaScript pur, tout y est. Cela me fait penser que TS n'implémente pas correctement les membres privés. Des pensées?

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

Tout comme pour la vérification de type, la confidentialité des membres n'est appliquée que dans le compilateur.

Une propriété privée est implémentée en tant que propriété standard et le code en dehors de la classe n'est pas autorisé à y accéder.

Pour rendre quelque chose de vraiment privé à l'intérieur de la classe, il ne peut pas être membre de la classe, ce serait une variable locale créée à l'intérieur d'une portée de fonction à l'intérieur du code qui crée l'objet. Cela signifierait que vous ne pouvez pas y accéder comme un membre de la classe, c'est-à-dire en utilisant le thismot - clé.

JavaScript prend en charge les variables privées.

function MyClass() {
    var myPrivateVar = 3;

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

Dans TypeScript, cela s'exprimerait comme suit:

class MyClass {

    doSomething: () => number;

    constructor() {
        var myPrivateVar = 3;

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

ÉDITER

Cette approche doit être utilisée avec parcimonie uniquement lorsque cela est absolument nécessaire. Par exemple, si vous devez mettre en cache un mot de passe temporairement.

L'utilisation de ce modèle entraîne des coûts de performance (sans rapport avec Javascript ou Typescript) et ne doit être utilisé que lorsque cela est absolument nécessaire.

Une fois que le support de WeakMap sera plus largement disponible, il y a une technique intéressante détaillée dans l'exemple n ° 3 ici .

Il permet des données privées ET évite les coûts de performance de l'exemple de Jason Evans en permettant aux données d'être accessibles à partir de méthodes prototypes plutôt que de méthodes d'instance uniquement.

La page MDN WeakMap liée répertorie la prise en charge des navigateurs sur Chrome 36, Firefox 6.0, IE 11, Opera 23 et 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)();
    }
  }
}

Depuis la sortie de TypeScript 3.8, vous pourrez déclarer un champ privé qui ne peut pas être consulté ou même détecté en dehors de la classe contenant .

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.

Les champs privés commencent par # caractère

Veuillez noter que ces champs privés seront différents des champs marqués avec private mot-clé

Réf. https://devblogs.microsoft.com/typescript/announcing-typescript-3-8-beta/

Merci à Sean Feldman pour le lien vers la discussion officielle sur cette question - voir sa réponse pour le lien.

J'ai lu la discussion à laquelle il a lié, et voici un résumé des points clés:

• Suggestion: propriétés privées dans le constructeur
  • problèmes: impossible d'accéder aux fonctions du prototype
• Suggestion: méthodes privées dans le constructeur
  • problèmes: comme pour les propriétés, plus vous perdez l'avantage de performance de créer une fonction une fois par classe dans le prototype; à la place, vous créez une copie de la fonction pour chaque instance
• Suggestion: ajoutez des règles standard à l'accès aux propriétés abstraites et appliquez la visibilité
  • problèmes: surcharge de performance majeure; TypeScript est conçu pour les grandes applications
• Suggestion: TypeScript encapsule déjà les définitions de méthode du constructeur et du prototype dans une fermeture; y mettre des méthodes et des propriétés privées
  • problèmes de placement de propriétés privées dans cette fermeture: elles deviennent des variables statiques; il n'y en a pas un par instance
  • problèmes liés à l'insertion de méthodes privées dans cette fermeture: elles n'y ont pas accès thissans une sorte de solution de contournement
• Suggestion: modifier automatiquement les noms des variables privées
  • counter arguments: c'est une convention de dénomination, pas une construction de langage. Mélangez-le vous-même
• Suggestion: annoter les méthodes privées avec@private minificateurs qui reconnaissent que l'annotation peut réduire efficacement les noms de méthodes
  • Aucun contre-argument significatif à celui-ci

Contre-arguments globaux pour ajouter la prise en charge de la visibilité dans le code émis:

• le problème est que JavaScript lui-même n'a pas de modificateurs de visibilité - ce n'est pas le problème de TypeScript
• il existe déjà un modèle établi dans la communauté JavaScript: préfixez les propriétés privées et les méthodes par un trait de soulignement, qui dit "procédez à vos risques et périls"
• lorsque les concepteurs de TypeScript ont dit que les propriétés et méthodes vraiment privées ne sont pas «possibles», elles signifiaient «pas possible sous nos contraintes de conception», en particulier:
  • Le JS émis est idiomatique
  • La plaque chauffante est minimale
  • Pas de surcharge supplémentaire par rapport à la POO JS normale

Dans TypeScript, les fonctions privées ne sont accessibles qu'à l'intérieur de la classe. Comme

Et il affichera une erreur lorsque vous essayez d'accéder à un membre privé. Voici l'exemple:

Remarque: ce sera bien avec javascript et les deux fonctions sont accessibles à l'extérieur.

Je me rends compte que c'est une discussion plus ancienne, mais il pourrait encore être utile de partager ma solution au problème des variables et méthodes supposées privées dans un TypeScript "fuyant" dans l'interface publique de la classe JavaScript compilée.

Pour moi, ce problème est purement cosmétique, c'est-à-dire qu'il s'agit de l'encombrement visuel lorsqu'une variable d'instance est visualisée dans DevTools. Ma solution consiste à regrouper les déclarations privées dans une autre classe qui est ensuite instanciée dans la classe principale et affectée à une privatevariable (mais toujours visible publiquement dans JS) avec un nom comme __(double tiret bas).

Exemple:

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

Lorsque l' myClassinstance est visualisée dans DevTools, au lieu de voir tous ses membres "privés" mélangés avec des membres vraiment publics (ce qui peut devenir très désordonné visuellement dans un code réel correctement refactoré), vous les voyez parfaitement regroupés dans la __propriété réduite :

Voici une approche réutilisable pour ajouter des propriétés privées appropriées:

/**
 * 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);
    }
}

Disons que vous avez une classe Clientquelque part qui a besoin de deux propriétés privées:

• prop1: string
• prop2: number

Voici comment vous l'implémentez:

// 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;
    }
}

Et si vous n'avez besoin que d'une propriété privée unique, cela devient encore plus simple, car vous n'auriez pas besoin d'en définir ClientPrivatedans ce cas.

Il convient de noter que, pour la plupart, la classe Privateoffre simplement une signature bien lisible, contrairement à l'utilisation directe de WeakMap.