Javascript: où définir ses méthodes ?

Il y a deux écoles: ceux qui préfèrent définir les méthodes d'un objet directement dans le constructeur de l'objet et ceux qui utilise le prototype du constructeur. Les premiers choisissent la possibilité de définir des propriétés privées - comme dans un langage objet orienté classe, les seconds ne veulent pas renoncer aux possibilités d'héritage et de monkey-patching offerte par le prototype.

Dans cet article, je vais décrire une technique qui permet de bénéficier à la fois du prototypage et du controle de visibilité des méthodes. Mais commençons par l'examen des deux façons classiques de définir des méthodes.

Javascript: comprendre la chaine des prototypes

Javascript est un langage objet sans classe. Par conséquent, essayer de comprendre l'héritage en javascript à travers des concepts d'autres langages (php, java) est une entreprise vaine.

Pour autant, le fait qu'il n'existe pas de classe ne veut pas dire pour autant que la notion d'héritage est inexistante.

Dans cette article, nous allons étudier une méthode basée sur le mécanisme des prototypes. Garder à l'esprit que ce n'est pas la seule méthode possible pour implémenter l'héritage.

Les closures en PHP : cela n'existe pas...

Avec la version 5.3, les "closures" ont fait leur entrée dans le monde PHP - Il était temps ! Cependant, l'implémentation de cette feature à de quoi décevoir, comme nous le verrons dans cet article.

Safe monkey patching en javascript

Formellement, le monkey patching consiste à modifier et étendre à l'éxécution des éléments du code déjà produits ou faisant partis du noyau d'un langage.

Autrement dit, agir sur des éléments déjà définis sans modifier le source (notamment celui de l'interpréteur).

Plus prosaïquement, il s'agit le plus souvent d'ajouter une méthode à un type natif, de redéfinir une méthode existante, ou - quand le langage le permet, de modifier le comportement des opérateurs ('+', '-', '==', etc.).