Apply minor fixes in '1-js/09-classes/04-private-protected-properties-methods/article.md'

Author: ArmandDelessert

1-js/09-classes/04-private-protected-properties-methods/article.md

@@ -11,34 +11,34 @@ Habituellement, les appareils que nous utilisons sont assez complexes. Mais dél
 
 ## Un exemple concret
 
-Par exemple, une machine à café. Simple de l'extérieur: un bouton, un écran, quelques trous ... Et le résultat: un café génial! :)
+Par exemple, une machine à café. Simple de l'extérieur : un bouton, un écran, quelques trous... Et le résultat : du bon café ! :)
 
 ![](coffee.jpg)
 
-Mais à l'intérieur ... (une image du manuel de réparation)
+Mais à l'intérieur... (une image du manuel de réparation)
 
 ![](coffee-inside.jpg)
 
 Beaucoup de détails. Mais on peut l'utiliser sans rien savoir.
 
-Les machines à café sont assez fiables, n'est-ce pas? Nous pouvons en utiliser une pendant des années, et seulement en cas de problème, la faire réparer.
+Les machines à café sont assez fiables, n'est-ce pas ? Nous pouvons en utiliser une pendant des années, et seulement en cas de problème, la faire réparer.
 
 Le secret de la fiabilité et de la simplicité d'une machine à café - tous les détails sont bien réglés et cachés à l'intérieur.
 
-Si nous retirons le capot de protection de la machine à café, son utilisation sera beaucoup plus complexe (où appuyer?) et dangereuse (elle peut électrocuter).
+Si nous retirons le capot de protection de la machine à café, son utilisation sera beaucoup plus complexe (où appuyer ?) et dangereuse (elle peut électrocuter).
 
 Comme nous le verrons, les objets de programmation ressemblent à des machines à café.
 
 Mais pour masquer les détails intérieurs, nous n'utiliserons pas une couverture de protection, mais une syntaxe spéciale du langage et des conventions.
 
 ## Interface interne et externe
 
-En programmation orientée objet, les propriétés et les méthodes sont divisées en deux groupes:
+En programmation orientée objet, les propriétés et les méthodes sont divisées en deux groupes :
 
 - *Interface interne* - méthodes et propriétés, accessibles à partir d'autres méthodes de la classe, mais pas de l'extérieur.
 - *Interface externe* - méthodes et propriétés, accessibles aussi de l'extérieur de la classe.
 
-Si nous continuons l'analogie avec la machine à café - ce qui est caché à l'intérieur: un tube de chaudière, un élément chauffant, etc. -, c'est son interface interne.
+Si nous continuons l'analogie avec la machine à café - ce qui est caché à l'intérieur : un tube de chaudière, un élément chauffant, etc. -, c'est son interface interne.
 
 Une interface interne est utilisée pour que l’objet fonctionne, ses détails s’utilisent les uns les autres. Par exemple, un tube de chaudière est attaché à l'élément chauffant.
 
@@ -48,20 +48,20 @@ Il suffit donc de connaître son interface externe pour utiliser un objet. Nous
 
 C'était une introduction générale.
 
-En JavaScript, il existe deux types de champs d’objet (propriétés et méthodes):
+En JavaScript, il existe deux types de champs d’objet (propriétés et méthodes) :
 
 - Publique : accessible de n'importe où. Ils comprennent l'interface externe. Jusqu'à présent, nous utilisions uniquement des propriétés et méthodes publiques.
 - Privée : accessible uniquement de l'intérieur de la classe. Ce sont pour l'interface interne.
 
-Dans de nombreuses autres langues, il existe également des champs "protégés": accessibles uniquement de l'intérieur de la classe et de ceux qui l'étendent (comme privé, mais avec accès des classes héritées). Ils sont également utiles pour l'interface interne. En un sens, elles sont plus répandues que les méthodes privées, car nous souhaitons généralement que les classes héritées puissent y accéder.
+Dans de nombreux autres langages, il existe également des champs "protégés" : accessibles uniquement de l'intérieur de la classe et de ceux qui l'étendent (comme privé, mais avec accès des classes héritées). Ils sont également utiles pour l'interface interne. En un sens, elles sont plus répandues que les méthodes privées, car nous souhaitons généralement que les classes héritées puissent y accéder.
 
-Les champs protégés ne sont pas implémentés en JavaScript au niveau de la langue, mais dans la pratique, ils sont très pratiques, ils sont donc imités.
+Les champs protégés ne sont pas implémentés en JavaScript au niveau du langage, mais dans la pratique, ils sont très pratiques, ils sont donc imités.
 
 Nous allons maintenant créer une machine à café en JavaScript avec tous ces types de propriétés. Une machine à café a beaucoup de détails, nous ne les modéliserons pas pour rester simples (bien que nous puissions).
 
 ## Protection de "waterAmount"
 
-Faisons d'abord une classe de machine à café simple:
+Faisons d'abord une classe de machine à café simple :
 
 ```js run
 class CoffeeMachine {
@@ -87,9 +87,9 @@ Changeons la propriété `waterAmount` en protégée pour avoir plus de contrôl
 
 **Les propriétés protégées sont généralement précédées d'un trait de soulignement `_`.**
 
-Cela n'est pas appliqué au niveau de la langue, mais il existe une convention bien connue entre les programmeurs selon laquelle ces propriétés et méthodes ne doivent pas être accessibles de l'extérieur.
+Cela n'est pas appliqué au niveau du langage, mais il existe une convention bien connue entre les programmeurs selon laquelle ces propriétés et méthodes ne doivent pas être accessibles de l'extérieur.
 
-Donc notre propriété s'appellera `_waterAmount`:
+Donc notre propriété s'appellera `_waterAmount` :
 
 ```js run
 class CoffeeMachine {
@@ -123,11 +123,11 @@ Maintenant, l'accès est sous contrôle, donc le réglage de l'eau en dessous de
 
 ## "power" en lecture seule
 
-Pour la propriété `power`, rendons-le en lecture seule. Il arrive parfois qu'une propriété doit être définie au moment de la création, puis ne jamais être modifiée.
+Pour la propriété `power`, rendons-la en lecture seule. Il arrive parfois qu'une propriété doit être définie au moment de la création, puis ne jamais être modifiée.
 
-C'est exactement le cas pour une machine à café: la puissance ne change jamais.
+C'est exactement le cas pour une machine à café : la puissance ne change jamais.
 
-Pour ce faire, il suffit de définir l'accésseur, mais pas le mutateur:
+Pour ce faire, il suffit de définir l'accésseur, mais pas le mutateur :
 
 ```js run
 class CoffeeMachine {
@@ -154,7 +154,7 @@ coffeeMachine.power = 25; // Error (no setter)
 ````smart header="Fonctions Accesseur/Mutateur"
 Ici, nous avons utilisé la syntaxe accesseur/mutateur.
 
-Mais la plupart du temps, les fonctions `get ... / set ...` sont préférées, comme ceci:
+Mais la plupart du temps, les fonctions `get...` / `set...` sont préférées, comme ceci :
 
 ```js
 class CoffeeMachine {
@@ -179,7 +179,7 @@ D'un autre côté, la syntaxe accesseur/mutateur est plus courte, donc il n'y a
 ````
 
 ```smart header="Les champs protégés sont hérités"
-Si nous héritons de `classe MegaMachine extends CoffeeMachine`, rien ne nous empêche d'accéder à` this._waterAmount` ou `this._power` à partir des méthodes de la nouvelle classe.
+Si nous héritons de `classe MegaMachine extends CoffeeMachine`, rien ne nous empêche d'accéder à `this._waterAmount` ou `this._power` à partir des méthodes de la nouvelle classe.
 
 Les champs protégés sont donc naturellement héritables. Contrairement aux champs privés que nous verrons ci-dessous.
 ```
@@ -188,9 +188,9 @@ Les champs protégés sont donc naturellement héritables. Contrairement aux cha
 
 [recent browser=none]
 
-Il existe une proposition JavaScript finie, presque dans la norme, qui fournit une prise en charge au niveau de la langue pour les propriétés et méthodes privées.
+Il existe une proposition JavaScript finie, presque dans la norme, qui fournit une prise en charge au niveau du langage pour les propriétés et méthodes privées.
 
-Les propriétés privées devraient commencer par `#`. Ils ne sont accessibles que de l'intérieur de la classe.
+Les propriétés privées devraient commencer par `#`. Elles ne sont accessibles que de l'intérieur de la classe.
 
 Par exemple, voici une propriété privée `#waterLimit` et la méthode privée de vérification du niveau de l'eau `#fixWaterAmount` :
 
@@ -222,10 +222,10 @@ coffeeMachine.#waterLimit = 1000; // Error
 */!*
 ```
 
-Au niveau de la langue, `#` est un signe spécial que le champ est privé. Nous ne pouvons pas y accéder de l'extérieur ou des classes héritées.
+Au niveau du langage, `#` est un signe spécial spécifiant que le champ est privé. Nous ne pouvons pas y accéder de l'extérieur ou des classes héritées.
 
 Les champs privés n'entrent pas en conflit avec les champs publics. Nous pouvons avoir les champs privés `#waterAmount` et publics `waterAmount` en même temps.
-Pour l'exemple, faisons de `waterAmount` un accesseur pour `#waterAmount`:
+Pour l'exemple, faisons de `waterAmount` un accesseur pour `#waterAmount` :
 
 ```js run
 class CoffeeMachine {
@@ -250,7 +250,7 @@ alert(machine.#waterAmount); // Error
 
 Contrairement aux champs protégés, les champs privés sont imposés par le langage lui-même. C'est une bonne chose.
 
-Mais si nous héritons de `CoffeeMachine`, nous n’aurons aucun accès direct à `#waterAmount`. Nous aurons besoin de compter sur l'accesseur/mutateur `waterAmount`:
+Mais si nous héritons de `CoffeeMachine`, nous n’aurons aucun accès direct à `#waterAmount`. Nous aurons besoin de compter sur l'accesseur/mutateur `waterAmount` :
 
 ```js
 class MegaCoffeeMachine extends CoffeeMachine {
@@ -267,7 +267,7 @@ Dans de nombreux scénarios, une telle limitation est trop sévère. Si nous ét
 ````warn header="Les champs privés ne sont pas disponibles par this[nom]"
 Les champs privés sont spéciaux.
 
-Comme nous le savons, nous pouvons généralement accéder aux champs en utilisant `this[name]`:
+Comme nous le savons, nous pouvons généralement accéder aux champs en utilisant `this[name]` :
 
 ```js
 class User {
@@ -279,23 +279,22 @@ class User {
 }
 ```
 
-C'est impossible avec les champs privés: `this['#name']` ne fonctionne pas. C'est une limitation de syntaxe pour assurer la confidentialité.
+C'est impossible avec les champs privés : `this['#name']` ne fonctionne pas. C'est une limitation de syntaxe pour assurer la confidentialité.
 ````
 
 ## Résumé
 
 En termes de POO, la délimitation de l'interface interne de l'interface externe est appelée [encapsulation]("https://fr.wikipedia.org/wiki/Encapsulation_(programmation)").
 
-Cela offre les avantages suivants:
+Cela offre les avantages suivants :
 
 Protection des utilisateurs pour qu'ils ne se tirent pas une balle dans le pied
 : Imaginez, il y a une équipe de développeurs utilisant une machine à café. Elle a été fabriquée par la société "Best CoffeeMachine" et fonctionne parfaitement, mais une coque de protection a été retirée. Donc, l'interface interne est exposée.
 
-
     Tous les développeurs sont civilisés - ils utilisent la machine à café comme prévu. Mais l'un d'entre eux, John, a décidé qu'il était le plus intelligent et a apporté quelques modifications aux éléments internes de la machine à café. La machine à café a donc échoué deux jours plus tard.
-    
+
     Ce n’est sûrement pas la faute de John, mais bien de la personne qui a enlevé le capot de protection et laissé John manipuler.
-    
+
     La même chose en programmation. Si un utilisateur d'une classe va changer des choses qui ne sont pas destinées à être modifiées de l'extérieur, les conséquences sont imprévisibles.
 
 Maintenable