Exemples détaillés des différences entre le mode Façade et le mode Médiateur dans la conception JavaScript

Le mode façade joue un rôle important dans l'architecture de cet article. Ce mode se reflète dans de nombreuses bibliothèques ou frameworks JavaScript. Le rôle le plus important est d'inclure une API de haut niveau pour masquer l'implémentation spécifique. exposez l'interface et nous pouvons réaliser l'implémentation interne nous-mêmes. Cela signifie également que le code d'implémentation interne peut être facilement modifié et mis à jour. Par exemple, si vous utilisez jQuery pour l'implémenter aujourd'hui et que vous souhaitez passer à YUI demain, alors. C'est très pratique.

Dans l'exemple suivant, vous pouvez voir que nous fournissons de nombreuses méthodes privées, puis exposons une API simple pour permettre au monde extérieur d'exécuter et d'appeler des méthodes internes :

var module = (function () {
 var _private = {
 i: 5,
 get: function () {
  console.log('current value:' + this.i);
 },
 set: function (val) {
  this.i = val;
 },
 run: function () {
  console.log('running');
 },
 jump: function () {
  console.log('jumping');
 }
 };
 return {
 facade: function (args) {
  _private.set(args.val);
  _private.get();
  if (args.run) {
  _private.run();
  }
 }
 }
} ());

module.facade({run:true, val:10});
//outputs current value: 10, running

La différence entre Facade et le médiateur dont nous parlons ci-dessous est que la façade ne fournit que les fonctions existantes, tandis que le médiateur peut ajouter de nouvelles fonctions.

Mode Médiateur

Avant de parler de modificateur, donnons un exemple Le système de contrôle de vol de l'aéroport, également connu sous le nom de tour légendaire, a des droits absolus. l'heure et le lieu de décollage et d'atterrissage de tout avion, et les avions et les avions n'étaient pas autorisés à communiquer auparavant. En d'autres termes, la tour est le cœur de l'aéroport et le médiateur est l'équivalent de cette tour.

Mediator est utilisé lorsqu'il y a plusieurs modules dans le programme et que vous ne voulez pas que chaque module ait des dépendances, alors l'objectif de contrôle centralisé peut être atteint grâce au mode médiateur. Dans des scénarios réels également, le médiateur encapsule de nombreux modules que vous ne souhaitez pas faire, leur permettant d'être connectés via le médiateur, tout en les couplant faiblement, de sorte qu'ils doivent communiquer via le médiateur.

Quels sont les avantages du mode médiateur ? Il s'agit du découplage. Si vous avez une bonne compréhension du modèle d'observateur auparavant, il est relativement simple de comprendre le diagramme de médiateur ci-dessous. L'image suivante est un diagramme de modèle de médiateur de haut niveau :

<🎜. >

Pensez-y, chaque module est un éditeur, et le médiateur est à la fois éditeur et abonné.

Le module 1 diffuse un fait au Mediator, indiquant que quelque chose doit être fait

Une fois que le Mediator a capturé le message, il démarre immédiatement le module 2 qui doit être utilisé pour traiter le message une fois le traitement terminé. , il renvoie les informations au Mediator
En même temps, Mediator démarre également le module 3. Lorsqu'il accepte le message renvoyé par le module 2, il enregistre automatiquement le journal dans le module 3.

Comme vous pouvez le voir , il n'y a pas de communication entre les modules. De plus, Mediator peut également mettre en œuvre la surveillance de l'état de chaque module, par exemple, si le module 3 a une erreur, Mediator ne peut temporairement penser qu'aux autres modules, puis redémarrer le module 3, et puis continuez l'exécution.

Avec le recul, nous pouvons voir que l'avantage du Mediator est que les modules faiblement couplés sont contrôlés par le même Mediator. Les modules n'ont besoin que de diffuser et d'écouter les événements, et il n'y a pas besoin de contact direct entre les modules. De plus, plusieurs modules peuvent être utilisés pour le traitement de l'information en même temps, et il est également pratique pour nous d'ajouter uniformément de nouveaux modules à la logique de contrôle existante à l'avenir.

Certainement : Comme tous les modules ne peuvent pas communiquer directement, il peut y avoir une légère diminution des performances, mais je pense que cela en vaut la peine.

Faisons une démo simple basée sur l'explication ci-dessus :

var mediator = (function(){
 var subscribe = function(channel, fn){
 if (!mediator.channels[channel]) mediator.channels[channel] = [];
 mediator.channels[channel].push({ context: this, callback: fn });
 return this;
 },
 
 publish = function(channel){
 if (!mediator.channels[channel]) return false;
 var args = Array.prototype.slice.call(arguments, 1);
 for (var i = 0, l = mediator.channels[channel].length; i < l; i++) {
  var subscription = mediator.channels[channel][i];
  subscription.callback.apply(subscription.context, args);
 }
 return this;
 };
 
 return {
 channels: {},
 publish: publish,
 subscribe: subscribe,
 installTo: function(obj){
  obj.subscribe = subscribe;
  obj.publish = publish;
 }
 };
 
}());

Ensuite, il y a 2 modules qui sont appelés séparément :

//Pub/sub on a centralized mediator
 
mediator.name = "tim";
mediator.subscribe('nameChange', function(arg){
 console.log(this.name);
 this.name = arg;
 console.log(this.name);
});
 
mediator.publish('nameChange', 'david'); //tim, david
 
 
//Pub/sub via third party mediator
 
var obj = { name: 'sam' };
mediator.installTo(obj);
obj.subscribe('nameChange', function(arg){
 console.log(this.name);
 this.name = arg;
 console.log(this.name);
});
 
obj.publish('nameChange', 'john'); //sam, john

Façade d'application : Une abstraction du cœur de l'application

Une façade fonctionne comme une abstraction du noyau de l'application, responsable de la communication entre le médiateur et le module. Chaque module ne peut communiquer avec le noyau du programme qu'à travers cette façade. En tant qu'abstraction, la responsabilité est de garantir qu'une interface cohérente (interface cohérente) peut être fournie à tout moment pour ces modules, similaire au rôle du contrôleur sendbox. Tous les composants du module communiquent avec le médiateur par son intermédiaire, la façade doit donc être fiable et digne de confiance. En même temps, en tant qu'interface pour le module, la façade doit également jouer un autre rôle, celui du contrôle de sécurité. c'est-à-dire décider à quelle partie du programme un module peut accéder. Les composants du module ne peuvent appeler que leurs propres méthodes et ne peuvent accéder à aucun contenu non autorisé. Par exemple, un module peut diffuser dataValidationCompletedWriteToDB, et le contrôle de sécurité ici doit garantir que le module dispose d'une autorisation d'écriture sur la base de données.

En bref, le médiateur ne peut traiter l'information qu'après détection d'autorisation de façade.

Médiateur d'application : le cœur de l'application

Le médiateur fonctionne comme le rôle principal de l'application. Parlons brièvement de ses responsabilités. La tâche principale consiste à gérer le cycle de vie du module. Lorsque ce noyau capture des informations entrantes, il doit déterminer comment le programme doit les gérer, c'est-à-dire décider quel ou quels modules démarrer ou arrêter. Lorsqu'un module démarre, il doit pouvoir s'exécuter automatiquement sans que le cœur de l'application décide s'il doit être exécuté (par exemple, s'il doit être exécuté lorsque le DOM est prêt), le module lui-même doit donc prendre une décision.

Vous avez peut-être encore des questions sur les circonstances dans lesquelles un module s'arrêtera. Lorsque le programme détecte qu'un module est en panne ou qu'une erreur s'est produite, le programme doit prendre une décision pour empêcher la méthode du module de continuer à être exécutée afin que le composant puisse être redémarré. L'objectif principal est d'améliorer l'utilisateur. expérience.

De plus, le noyau devrait être capable d'ajouter ou de supprimer dynamiquement des modules sans affecter les autres fonctions. Un exemple courant est qu'un module n'est pas disponible au début du chargement de la page, mais après l'opération de l'utilisateur, le module doit être chargé et exécuté dynamiquement, tout comme la fonction de chat dans Gmail, il devrait l'être. très bien. Comprenez-le.

La gestion des erreurs d'exception est également gérée par le cœur de l'application. De plus, lorsque chaque module diffuse des informations, il diffuse également toutes les erreurs au cœur afin que le cœur du programme puisse arrêter/redémarrer ces modules en fonction de la situation. Il s'agit également d'une partie importante de l'architecture faiblement couplée. Nous n'avons pas besoin de modifier manuellement les modules. Nous pouvons le faire en utilisant la publication/abonnement via le médiateur.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!