Dans le dernier numéro, nous avons discuté de la conception du composant de gestion de file d'attente et lui avons donné un nom fort et unique : Smart Queue. Cette fois, nous allons mettre en pratique les résultats de la conception précédente et l'implémenter avec du code.
Tout d’abord, nous devons considérer la disposition du fichier source, c’est-à-dire décider comment diviser le code en fichiers indépendants. Pourquoi faire ça ? Vous vous souvenez qu'à la fin du dernier numéro, j'ai mentionné que ce composant utiliserait du « code externe » ? Afin de distinguer l'objectif du code, il a été décidé de diviser le code en au moins deux parties : le fichier de code externe et le fichier Smart Queue.
La différenciation des objectifs n'en est qu'une, et deuxièmement, les disperser dans des fichiers indépendants est bénéfique pour la maintenance du code. Imaginez qu'un jour dans le futur vous décidiez d'ajouter de nouvelles fonctions étendues aux fonctions de base existantes de gestion de files d'attente, ou de les regrouper dans un composant qui implémente une tâche spécifique, mais que vous souhaitiez conserver les fonctions existantes (implémentation interne) et les appels. (interface externe) reste inchangée, alors écrire le nouveau code dans un fichier séparé est le meilleur choix.
Eh bien, la prochaine fois, nous nous concentrerons sur le sujet de la présentation des fichiers, venons-en maintenant au fait. La première étape, bien entendu, consiste à créer son propre espace de noms pour le composant. Tout le code du composant sera limité à cet espace de noms de niveau supérieur :
var SmartQueue = window.SmartQueue ||
SmartQueue.version = '0.1';
Lors de l'initialisation, si vous rencontrez un conflit d'espace de noms, arrêtez-le et utilisez-le. Habituellement, ce conflit est provoqué par une référence répétée au code du composant, donc "pull over" réécrira l'objet avec la même implémentation dans le pire des cas, s'il y a un autre objet sur la page également appelé SmartQueue, c'est embarrassant, je le ferais. remplacez votre implémentation - s'il n'y a plus de conflits de noms, les deux composants peuvent s'exécuter sans incident. Donnez-lui également un numéro de version.
Ensuite, créez trois files d'attente pour SmartQueue selon trois priorités :
var Q = SmartQueue.Queue = [[], [], []];
Chacun est un tableau vide car aucune tâche n’a encore été ajoutée. Et au fait, créez un "raccourci" pour celui-ci. Si vous souhaitez accéder au tableau plus tard, écrivez simplement Q[n].
Ensuite, notre protagoniste Task fait une grande apparition - comment créer une nouvelle tâche est défini ici :
Je n'entrerai pas dans les détails spécifiques à l'intérieur. Avec les commentaires nécessaires, notre code peut généralement être auto-descriptif, et il en va de même pour les codes suivants. Ici, nous disons au client (utilisateur) : si vous souhaitez créer une nouvelle instance de SmartQueue.Task, vous devez transmettre au moins un paramètre à ce constructeur (les trois derniers peuvent être omis pour le traitement par défaut), sinon une exception sera levée.
Mais cela ne suffit pas. Parfois, les clients souhaitent cloner une nouvelle instance à partir d'une tâche existante ou réparer un « corps sain » (une véritable instance d'objet de tâche) à partir d'un « corps désactivé » (un objet avec certains attributs de tâche). La méthode de construction ci-dessus est un peu inconfortable - le client doit écrire comme ceci :
var task1 = new SmartQueue.Task(obj.fn, 1, '', obj.dependencies);
Source : Alipay UED
var T = SmartQueue.Task = function (fn, niveau, nom, dépendances) {
if(typeoffn !== FONCTION) {
throw new Error('Type d'argument invalide : fn.');
}
ceci.fn = fn;
this.level = _validateLevel(level) ? niveau : LEVEL_NORMAL;
// détecte le type de nom
this.name = typeof name === STRING && name nom : 't' + _id++;
// les dépendances peuvent être récupérées en tant qu'"objet", utilisez donc instanceof à la place.
this.dependencies = dépendances instanceof Array ? dépendances : [];
} ;