Je regarde la mise en œuvre des députés dactylographiée, et je trouve un peu confus. IntelliSense ne permet pas d'accéder à un membre privé, mais en JavaScript pur, il est là. Cela me fait penser que TS ne met pas en œuvre correctement les membres privés. Des pensées?
class Test{
private member: any = private member;
}
alert(new Test().member);
Tout comme avec la vérification de type, la vie privée des membres ne sont appliquées dans le compilateur.
Une propriété privée est mis en œuvre comme une propriété régulière et le code en dehors de la classe n'est pas autorisé à y accéder.
Pour faire 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' un champ de fonction à l' intérieur du code qui crée l'objet. Cela signifie que vous ne pouvez pas y accéder comme un membre de la classe, soit en utilisant le thismot - clé.
JavaScript prend en charge les variables privées.
function MyClass() {
var myPrivateVar = 3;
this.doSomething = function() {
return myPrivateVar++;
}
}
Dactylographiée ce serait exprimé comme ceci:
class MyClass {
doSomething: () => number;
constructor() {
var myPrivateVar = 3;
this.doSomething = function () {
return myPrivateVar++;
}
}
}
MODIFIER
Cette approche ne doit être utilisé SPARINGLY où il est absolument nécessaire. Par exemple , si vous avez besoin de mettre en cache un mot de passe temporaire.
Il y a des coûts de performance à l'utilisation de ce modèle (hors de propos de Javascript ou Tapuscrit) et ne doivent être utilisées lorsque cela est absolument nécessaire.
Une fois que le soutien pour WeakMap est plus largement disponible , il est une technique intéressante détaillée dans l' exemple # 3 ici .
Il permet des données privées et évite les coûts de performance de l'exemple Jason Evans en permettant que les données soient accessibles à partir de méthodes de prototypes au lieu de seulement les méthodes d'instance.
Le support des listes de pages liées WeakMap du navigateur MDN à Chrome 36, Firefox 6.0, Internet Explorer 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)();
}
}
}
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 , il lié, et voici un résumé des points clés:
thissans une sorte de solution de contournement@privatedonc minifiers qui reconnaissent que l' annotation peut rapetisser efficacement les noms de méthode
contre-arguments globaux pour ajouter le support de visibilité dans le code émis:
Dactylographiée fonctions privées ne sont accessibles que dans la classe. Comme
Et il affiche une erreur lorsque vous essayez d'accéder à un membre privé. Voici l'exemple:
Note: Il sera très bien avec javascript et les deux fonctions sont accessibles à l'extérieur.
Je sais que cela est une discussion plus, mais il pourrait encore être utile de partager ma solution au problème des variables et des méthodes soi-disant privées dans un tapuscrit « fuite » dans l'interface publique de la classe JavaScript compilé.
Pour moi , cette question est purement cosmétique, à savoir qu'il est tout au sujet de l'encombrement visuel quand une variable d'instance est considérée dans DevTools. Mon correctif est aux déclarations privées de regrouper dans une autre classe qui est ensuite instancié dans la classe principale et affecté à un private(mais toujours visible publiquement dans JS) variable avec un nom comme __( un double underscore).
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 considérée dans DevTools, au lieu de voir tous ses membres entremêlés avec les publics véritablement « privés » (qui peut obtenir visuellement très salissante correctement refondus Code de la vie réelle) vous les voyez clairement groupés dans la affaissée __propriété:
Beaucoup de gens prétendent cela est impossible en raison des limitations en JavaScript. Je dirais qu'il est dans les limites de la créativité des développeurs JavaScript.
Je développe une bibliothèque en ce moment qui permet aux membres héritables privés et protégés des classes, ainsi que des interfaces, etc. appelé ClassJS. Check it out ici sur GitHub .