[Article] Usage avanc� des fonctions JavaScript

:salut:

Pour faire suite � Trois fondamentaux de JavaScript, Jean-Pierre Vincent vous propose un nouvel article : Usage avanc� des fonctions JavaScript.

Citation:

---

Admettons donc que vous ayez dig�r� sans probl�me les port�es et les fonctions, passons � deux choses vraiment particuli�res � JavaScript :

1. Le renvoi de fonction qui permet de belles optimisations et qui ouvre la voie � des patterns que les amoureux de la th�orie du langage appr�cieront ;
2. Une impl�mentation de classe statique, pour reprendre le terme utilis� en PHP ou en Java.

Et enfin nous verrons une proposition d'impl�mentation de deux design pattern c�l�bres et particuli�rement utiles en JavaScript : Singleton et Factory.

---

:fleche: Usage avanc� des fonctions JavaScript

N'h�sitez pas � faire part de vos remarques, commentaires et / ou encouragements � l'auteur.

:merci: � lui !

encore un tr�s bon article :-)

Ce qui suit n'est pas une critique sur l'article lui m�me mais une r�flexion g�n�rale :

Le probl�me , comme pour les pseudo "classes" en javascript, est que les constructions et structures des autres langages "objets" sont justes mim�es en ECMASCRIPT 3.X. C'est en fait l'une des cons�quence du pattern "prototype" utilis� pour g�n�rer des objets en javascript.

Ce qui signifie que la classe "statique" ne l'est que pour l'auteur du script , il n'y a rien de contraignant pour un "client" du script puisque qu'on pourra toujours modifier l'objet de d�part. En gros c'est comme si on rajoutait dans le script en commentaire " cette classe est statique " , mais rien n'existe pour obliger le client ( qui ne touche pas au script de d�part ) � se servir de cette classe "statique" d'une mani�re strictement statique. C'est bien la diff�rence entre javascript , et d'autres langages comme java ou php ou l'on peut contraindre la mani�re d'utiliser un objet tant le client de l'objet ne touche pas � la classe de d�part.

Au finalement tout se passe dans la t�te de l'auteur du script et rien ne peut �tre v�ritablement formalis� strictement.

Ma remarque ne s'applique bien sur pas � ECMASCRIPT 5 ou l'on peut "freezer" un objet , formalisant donc une configuration particuli�re.

un petit exemple : on peut appel� un objet d�fini d'au moins 3 mani�re :

Code:

---

1 2 3 4

var myObject = myClass ; var myObject = myClass(); var myObject = new myClass();

---

avec des r�sultats compl�tement diff�rent.
comment savoir de quelle mani�re appeller l'object myClass de la bonne mani�re sans une indication de la bonne mani�re de l'appeler ?

en java je n'ai pas le choix je dois faire

Code:

---

1 2	MyClass myClass = new MyClass();

---

Cependant je connais avec certitude le r�sultat de mon instruction.

Un article tr�s int�ressant , encore une fois !

La partie sur les fonctions anonyme de l'�v�nement onload, est le plus important je pense. M�me apr�s des ann�es de d�veloppement , il m'arrive de me faire encore avoir. Difficile de comprendre par soi m�me ces comportements, pour un d�butant, sans un bon tuto!
A not� qu'il y'a d'autres moyens similaire de faire ceci. Dans l'approche d'une boucle, un forEach aurait eu le m�me effet. L'utilisation du currying aussi, comme indiqu� dans l'article , qui est maintenant standardis� via la fonction bind de l'objet Function. La plus part des librairies inclue ces fonctionnabilit�, qui au final ce base toute sur une port� alternative...
Il existe une autre approche encore tr�s mal support�. Il s'agit du mot cl� let. Let n'agit non pas en red�finissant la variable, mais en n'en cr�ant une nouvelle, du m�me non, qui seulement applique au bloque courant.

du coup l'exemple devienderait

Code:

---

1 2 3 4 5 6 7 8 9 10

for(let i = 0; i < queries.length; i++) { queries[i].onload = function(i) { console.log( i ); // valeur }; } // plus tard ... queries[ 0 ].onload(); // 0 queries[ 1 ].onload(); // 1 queries[ 2 ].onload(); // 2

---

let est � utilis� bien sur dans un environnement sp�cifique, le supportant

Comme j'aime chipoter, l'exemple onDOMEvent n' est pas le plus judicieux.
Aucune variable n'est d�clar� dans la port� de la fonction auto-executante. Du coup , pas besoin de passer par elle. Un simple teste conditionnelle aurait pu faire l'affaire. M�me si bien sur l�int�r�t n'�tais l�....

Concernant le design singleton, j'aurais bien des petit hack � propos�, qui reste du bidouillage tout de m�me.
Le premier , inclure dans le constructeur un param�tre priv�, d�clar� dans la port� de la fonction auto-execut�. Par exemple

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

(function(){   var objTestPrivate = {}, instance;   // constructeur MY.utils.XHR=function( url, objTesteConstructeur ){ if(objTesteConstructeur !== objTestPrivate ) throw new Error('please use MY.utils.XHR.getInstance()'); .... };   MY.utils.XHR.getInstance = function( url ) { if(instance ) { return instance ; // on crée, on enregistre, on renvoie } else { return instance = MY.utils.XHR(url, objTestPrivate ); } }; })();

---

Ou alors de passer par les propri�t�s de l'objet arguments , callee et caller, mais qui ne sont plus standardis� depuis ECMA5, du moins en mode strict

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

// constructeur MY.utils.XHR=function( url){ if(arguments.callee.caller != MY.utils.XHR.getInstance ) throw new Error('please use MY.utils.XHR.getInstance()'); .... };   MY.utils.XHR.getInstance = function(){ var instance; return function( url ) { if(instance ) { return instance ; // on crée, on enregistre, on renvoie } else { return instance= MY.utils.XHR(url); } }; }()

---

d�cid�ment, developpez.net, c'est de la balle.

On demande plus de ces types d'articles :ccool: