Pourquoi est-il mauvais d'utiliser des getters et des setters en JavaScript ?

Comme vous le savez, les getters et les setters font désormais partie de JavaScript. Ils prennent largement en charge tous les principaux navigateurs, même IE8.

Je ne pense pas que cette idée soit généralement fausse, mais je pense qu'elle n'est pas très adaptée à JavaScript. Il peut sembler que les getters et les setters simplifient le code et font gagner du temps, mais ils introduisent en réalité des erreurs cachées qui ne sont pas évidentes à première vue.

Comment fonctionnent les getters et les setters ?

Tout d'abord, un petit résumé de ce que c'est :

Parfois, nous souhaitons autoriser l'accès à une propriété qui renvoie une valeur calculée dynamiquement, ou vous souhaiterez peut-être refléter l'état d'une variable interne, sans utiliser d'appels de méthode explicites.

Pour illustrer leur fonctionnement, regardons un objet personne avec deux propriétés : firstName et lastName, et une valeur calculée : fullName.

var obj = {
  firstName: "Maks",
  lastName: "Nemisj"
}

La valeur calculée fullName renverra la concaténation de firstName et lastName.

Object.defineProperty(person, 'fullName', {
  get: function () {
    return this.firstName + ' ' + this.lastName;
  }
});

Pour obtenir la valeur calculée de fullName, il n'est pas nécessaire d'utiliser les horribles parenthèses comme person.fullName(), utilisez simplement var fullName = person.fullName.

Il en va de même pour les setters, vous pouvez définir la valeur en utilisant une fonction :

Object.defineProperty(person, 'fullName', {
  set: function (value) {
    var names = value.split(' ');
    this.firstName = names[0];
    this.lastName = names[1];
  }
});

L'utilisation est aussi simple qu'un getter : person.fullName = 'Boris Gorbachev'. Cela appellera la fonction définie ci-dessus et séparera Boris Gorbatchev en firstName et lastName.

Quel est le problème ?

Vous pensez peut-être : "Hé, j'aime les méthodes getter et setter, elles semblent plus naturelles, comme JSON. Vous avez raison, elles le sont, mais prenons un peu de recul. Un coup d'oeil." comment fonctionne fullName avant les getters et les setters.

Pour obtenir la valeur, nous utiliserons quelque chose comme getFullName(), et pour définir la valeur, nous utiliserons person.setFullName('Maks Nemisj').

Que se passera-t-il si le nom de la fonction est mal orthographié et que person.getFullName() est écrit sous la forme person.getFulName() ?

JavaScript donnera une erreur :

person.getFulName();
       ^
TypeError: undefined is not a function

Cette erreur sera déclenchée au bon moment et au bon endroit. Accéder à un objet où la fonction n'existe pas déclenchera une erreur - c'est bien.

Maintenant, voyons ce qui se passe lorsque nous utilisons un passeur avec un mauvais nom ?

person.fulName = 'Boris Gorbachev';

Rien. Les objets sont extensibles et les clés et valeurs peuvent être attribuées dynamiquement, de sorte qu'aucune erreur ne sera générée lors de l'exécution.

Un tel comportement signifie qu'une erreur peut apparaître quelque part dans l'interface utilisateur, ou lorsqu'une opération est effectuée sur une valeur incorrecte, plutôt qu'au moment d'une faute de frappe.

C'est tellement intéressant de suivre les bugs qui auraient dû se produire dans le passé mais qui apparaissent dans le futur flux de code.

Le sceau est-il possible ?

Ce problème peut être partiellement résolu grâce à sealAPI. Tant que l'objet est scellé, il ne peut pas être muté, ce qui signifie que fulName tentera d'attribuer une nouvelle clé à l'objet personne et qu'il échouera.

Pour une raison quelconque, lorsque j'ai testé cela dans Node.js V4.0, cela n'a pas fonctionné comme prévu. Je ne peux donc pas garantir cette solution.

Ce qui est encore plus frustrant, c’est qu’il n’y a aucune solution pour les passeurs. Comme je l'ai mentionné plus tôt, les objets sont extensibles et sécurisés, ce qui signifie que l'accès à une clé inexistante ne provoquera aucune erreur.

Si cette situation ne s'appliquait qu'aux littéraux d'objets, je ne prendrais pas la peine d'écrire cet article, mais après ECMAScript 2015 (ES6) et l'essor de la possibilité de définir des getters et des setters avec des classes, j'ai décidé d'écrire un blog. sur les pièges potentiels.

L'arrivée des classes

Je sais qu'actuellement les classes ne sont pas très populaires dans certaines communautés JavaScript. Les gens se demandent s'ils sont nécessaires dans des langages fonctionnels/basés sur des prototypes tels que JavaScript. Cependant, le fait est que les classes font partie de la spécification ECMAScript 2015 (ES6) et le seront pendant un certain temps.

Pour moi, les classes sont un moyen de spécifier une API bien définie entre le monde externe de la classe (les consommateurs) et le monde interne de l'application. Il s’agit d’une abstraction qui met les règles en noir sur blanc, et nous supposons que ces règles ne changeront pas de sitôt.

Améliorez l'objet personne et faites-en une vraie classe. Person définit une interface pour obtenir et définir fullName. La classe

class Person {
  constructor(firstName, lastName) {
    this.firstName = firstName;
    this.lastName = lastName;
  }
  getFullName() {
    return this.firstName + ' ' + this.lastName;
  }
  setFullName(value) {
    var names = value.split(' ');
    this.firstName = names[0];
    this.lastName = names[1];
  }
}

définit une description d'interface stricte, mais les méthodes getter et setter la rendent moins stricte. Nous sommes habitués aux erreurs gonflées lorsque nous travaillons avec des littéraux d'objet et aux fautes d'orthographe dans les clés lorsque nous travaillons avec JSON. J'aimerais au moins que les cours soient plus rigoureux et, en ce sens, fournissent un meilleur feedback aux développeurs.

Bien que cette situation ne soit pas différente lors de la définition des getters et setters sur une classe. Mais cela n’empêchera personne de mal l’épeler.

class Person {
  constructor(firstName, lastName) {
    this.firstName = firstName;
    this.lastName = lastName;
  }
  get fullName() {
    return this.firstName + ' ' + this.lastName;
  }
  set fullName(value) {
    var names = value.split(' ');
    this.firstName = names[0];
    this.lastName = names[1];
  }
}

Les exécutions avec des fautes de frappe ne donneront aucune erreur :

var person = new Person('Maks', 'Nemisj');
console.log(person.fulName);

Le même comportement laxiste, verbeux et introuvable peut conduire à des erreurs.

在我发现这一点后，我有一个问题：在使用getter和setter的时候，有没有什么可以做的，以便于使得类更严格？我发现：有是肯定有，但是这值得吗？增加额外层次的复杂性到代码就只是为了使用数量更少的括号？对于API定义，也可以不使用getter和setter，而这样一来就能解决这个问题。除非你是一个铁杆开发人员，并愿意继续进行，不然还有另一种解决方案，如下所述。

proxy来帮助？

除了getter和setter方法，ECMAScript 2015（ES6）还自带proxy对象。proxy可以帮助你确定委托方法，这些委托方法可以在实际访问键执行之前，用来执行各种操作。事实上，它看起来像动态getter / setter方法。

proxy对象可以用来捕捉任何到类的实例的访问，并且如果在类中没有找到预先定义的getter或setter就会抛出错误。

为了做到这一点，必须执行下面两个操作：

• 创建基于Person原型的getter和setter清单。

• 创建将测试这些清单的Proxy对象。

让我们来实现它。

首先，为了找出什么样的getter和setter方法可以用在类Person上，可以使用getOwnPropertyNames和getOwnPropertyDescriptor：

var names = Object.getOwnPropertyNames(Person.prototype);
var getters = names.filter((name) => {
  var result =  Object.getOwnPropertyDescriptor(Person.prototype, name);
  return !!result.get;
});
var setters = names.filter((name) => {
  var result =  Object.getOwnPropertyDescriptor(Person.prototype, name);
  return !!result.set;
});

在此之后，创建一个Proxy对象：

var handler = {
  get(target, name) {
    if (getters.indexOf(name) != -1) {
      return target[name];
    }
    throw new Error('Getter "' + name + '" not found in "Person"');
  },
  set(target, name) {
    if (setters.indexOf(name) != -1) {
      return target[name];
    }
    throw new Error('Setter "' + name + '" not found in "Person"');
  }
};
person = new Proxy(person, handler);

现在，只要你尝试访问person.fulName，就会显示Error: Getter “fulName” not found in “Person”的消息。

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!