DRY code, correction de mon code

Bonjour à tous et merci d'avance pour votre aide.
Mon code fonctionne, mais j'aurais souhaité avoir du code plus propre, plus concis.

Voici ma classe qui me permet de consulter un serveur Redis et entre autre avec l'une de ces méthode "checkUser".

Code:

---

1 2 3 4 5 6 7 8 9 10 11

redisProcess = { checkUser : function (token, callback){ redis_client.SISMEMBER('user:' + token, function (err, res) { if (err || res == 0){ callback(false); }else{ callback(true); } }); } }

---

Et à chaque reprise où j'ai besoin de ma méthode checkUser, je dois répéter ce bloc.

Code:

---

1 2 3 4 5 6 7 8

redisProcess.checkUser(token, function(err, data){ if(!err){ console.log(err); return false }else{ //J'éxécute mon code } });

---

J'avais tenter un try catch, mais l'aspect asynchrone du code ma posé problème.
Merci à vous;

Citation:

---

Envoyé par Rifton007

Bonjour à tous et merci d'avance pour votre aide.
Mon code fonctionne, mais j'aurais souhaité avoir du code plus propre, plus concis.
...

---

Bonjour pour un code concis une toute petite chose éviter les [CODEinline]if (true) true else false[CODEinline] ou les [CODEinline]if (true) false else true[CODEinline]

Code:

---

1 2 3 4 5

if (err || res == 0){ callback(false); }else{ callback(true); }

---

en supprimant la code inutile callback(!(err || res == 0));pour le reste je ne comprends pas le code.

Code:

---

1 2	function(err, data){ if(!err){

---

est une fonction avec deux arguments mais l'appel se fait via callback(false); qui n'a qu'un argument.

ensuite j'ai du mal avec la sémantique

Code:

---

1 2 3 4 5

if (err || res == 0){ callback(false); }else{ callback(true); }

---

si il y une erreur ou que le resultat est 0 appeler la callback avec false. puis la callback re-teste cet argument

Code:

---

1 2	function(err, data){ if(!err){

---

si on avait pas d'erreur on a passé false et on test si non err donc si non false donc true.
au final ça donne si on a une erreur on passe false puis si not err alors erreur !!!

c'est plutôt compliqué. pourquoi err est un argument qui vaut false si err et true sinon
soit il faut l'appeler success soit il y a une série de not pour rien.


je ne vois pas l'utilité des deux fonction anonymes.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

redisProcess = { checkUser : function (token, callback){ redis_client.SISMEMBER('user:' + token, callback); } }   redisProcess.checkUser(token, function(err, data){ if(err || res == 0){ console.log(err); return false }else{ //J'éxécute mon code } });

---

Dans les appels asynchrone susceptibles d'échouer je préfère les notion descope success et echec.

Code:

---

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

redisProcess = { checkUser : function (scope){ redis_client.SISMEMBER('user:' + scope.token, function (err, res) { if (err || res == 0){ scope.success(res); }else{ scope.failed(err, res); } }); } }   redisProcess.checkUser({ "token": token, "success": function(data){ //J'éxécute mon code // parmis les avantage on peut ajouter les membres que l'on veut au scope lors de l'appel // est les utiliser ici console.log(this.perso); }, "failed": function(err, data){ console.log(err); return false; }, "perso": 45; //un membre ajouté au scope lors de l'appel. });

---

A+JYT

Merci de ton aide Sekaijin

Citation:

---

en supprimant la code inutile callback(!(err || res == 0));pour le reste je ne comprends pas le code.

---

Je te l'accorde mon code se passe de tout commentaire.
Et c'est ma plus grande frustration quelque soit le langage, c'est de ne pas pouvoir passer à la vitesse supérieur.
J'ai beau lire, suivre des tutorial, j'éprouve toujours des difficulté à raisonné POO.
Objet, classe, méthode, interface, namespace, prototype, mais rien à faire je m'y noie toujours.

En tout cas merci pour ton code, on va le reprendre ensemble pour voir si j'ai bien compris.

Code:

---

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

redisProcess = { // Je crée mon objet redisProcess checkUser : function (scope){ // je crée ma méthode checkUser avec comme argument un objet (scope) redis_client.SISMEMBER('user:' + scope.token, function (err, res) { if (err || res == 0){ scope.success(res); // j'appelle ma méthode sucess de l'objet scope }else{ scope.failed(err, res); } }); } }   redisProcess.checkUser({ // j'appelle la méthode checkUser "token": token, "success": function(data){ //J'éxécute mon code // parmis les avantage on peut ajouter les membres que l'on veut au scope lors de l'appel // est les utiliser ici console.log(this.perso); }, "failed": function(err, data){ console.log(err); return false; }, "perso": 45; //par contre j'ai pas compris: un membre ajouté au scope lors de l'appel. });

---

Le termes 'scope' est nouveau pour moi.
Cela veux dire quoi plus exactement.

Merci à toi

scope ou contexte c'est le contexte à utiliser pour exécuter les méthodes lors du callback

suppose que tu ai une méthode comme celle que tu as définieredisProcess.checkUserMaintenant tu fais un appel et tu as une variable que tu voudrais utiliser dans la callback

Code:

---

1 2 3 4 5 6 7 8

function maFonction() { var uneVariable = 45; redisProcess.checkUser(token, function(err, data) { //ici je voudrais utiliser maVariable //cela ne pose pas de problème car dans Javascript la porté des variable le permet console.log(uneVariable); }); }

---

tu te dit cool mais moi j'ai pas une fonction avec une variable mais un objet qui as un membre et des méthodes je vais faire pareil

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

anObject = { uneVariable: 45, afterCall: function(err, data) { //ici je voudrais utiliser maVariable //cela ne pose pas de problème car dans Javascript la porté des variable le permet console.log(this.uneVariable); }, run : function () { redisProcess.checkUser(token, this.afterCall); } } anObject.run();

---

tu appelle bien checkUser avec comme callback ta méthode afterCall
Mais l'objet anObject n'est pas connu de la méthode checkUser du coup lorsque la réponse arrive l'appel à afterCall qui va exécuter this.maVariable mais this n'est pas une référence à anObject mais une référence à redisProcess et ça plante.

l'idée qui se cache derrière scope est de définir un contexte qui sera utilisé lors de la réponse. ainsi le corps des méthodes du scope auront accès à tous ce qui est mis dedans lors de l'appel. il ne s'agit que d'un simple objet.

Objet, classe, méthode, interface, namespace, prototype
on peut simplifier pour y voir clair

dans la programmation procédurale on a des variables (entier booléen string etc.) des structures (array, list, map...) des procédures et des fonctions.

dans la POO on a plusieurs façon d'aborder la programmation.

la POO à base de classe. la notion de classe est directement issue de la classification (comme pour la biologie)
on peut dire qu'un poussin est un oiseau qui est un animal. chacune de ces "catégorie" est une classe.
titi est un oiseau donc un animal c'est une instance de la classe oiseau.
dans cette approche on défini des classes qui contiennent la définition de membres (les attributs de la classe par exemple dans la classe animal l'attribut nombre de pattes) on définit des méthodes (les actions que l'on peut effectuer sur la classe)
le développeur défini donc des classes. il lui faut aussi un moyen de créer des instances. car sans ça impossible d'avoir notre titi à partir de la classe oiseau. pour cela on défini des constructeurs.

la POO à base de prototype ne définie aucune catégorie. mais ce concentre sur la façon dont on construit des objets. on défini des "modèles" des objet que l'on veut manipuler et on a un moyen d'en fabriquer autant que l'on veut conforme au "modèle". cela s'appelle un prototype. exactement ce qu'on fait dans l'industrie (automobile par exemple) la encore les objects on des attributs appelé membres. des des actions possible appelées méthodes.

une "fonction" définie dans une classe ou un objet s'appelle une méthode. la différence avec la programmation procédurale est que la méthode possède une référence implicite à l'objet qui la porte. cette référence s'appelle this.

voila pour les bases. il existe des langages qui n'ajoute rien.

on a vu qu'un poussin est un oiseau qui est un animal on a donc une notion d'héritage. cette notion existe aussi pour les prototypes. un prototype possède un prototype qui possède un prototype qui possède...

la notion d'interface à été introduite par les langages à base de classe qui ne gèrent que l'héritage simple.
une classe n'hérite que d'une seule autre.
du coup comment gérer les "trucs" qui volent. une interface est un contrat une classe qui implémente une interface s'engage à fournir toutes les méthodes prévues dans le contrat. ainsi si j'ai une référence à un objet qui implémente l'interface "trucs" qui volent je sais que je peux appeler la méthode "vole".

les namespaces n'a absolument rien à voir avec les différents type de programmation.
ils vise à résoudre un problème simple comment utiliser deux outils qui définissent tous les deux le même nom pour des chose différente. par exemple dans mon appli j'utilise une librairie qui gère l'authentification et défini une variable nommée user. mais voila j'utilise aussi une librairie qui permet de se connecter à un système distant et qui définie elle aussi une variable user mais elle n'a rien à voir avec l'autre.
l'idées des namespaces est de définir chacune des deux variable dans deux espace différent. ainsi je peux avoir les deux variable en même temp.

pour ecmascript pas de classe pas d'interface pas de namespaces

on a des objets et des prototypes ça fait plutôt court. mais on fait tout avec.
le langage permet de définir une méthode/fonction que l'on attache à un prototype, ou un objet, ou au contexte global, ou que l'on passe en paramètre d'une autre méthode/fonction
on a bien sur les type de base nombre, string et bool et les tableaux.
comme on peut ajouter les méthodes que l'on veut à n'importe quel objet pas besoin d'interface.
qu'en au namespaces on défini les objets dans d'autres objets. ce qui est généralement suffisent pour gérer les conflit de nom.

A+JYT

Merci infiniment sekaijin pour toutes ces explications.
C'est bien plus claire pour moi.