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