Discussion :

[Bovino]

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

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.

Usage avanc� des fonctions JavaScript

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

� lui !

[le_chomeur]

encore un tr�s bon article :-)

[camus3]

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
 
MyClass myClass = new MyClass();

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

[kimjoa]

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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);
    }
};
}()

[Nalexx]

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

On demande plus de ces types d'articles