Façade contre médiateur
J'ai étudié la différence entre ces deux modèles.
Je comprends que la façade encapsule l’accès à un sous-système et que le médiateur encapsule les interactions entre les composants.
Je comprends que les composants du sous-système ne sont pas conscients de la façade, alors que les composants sont évidemment conscients du médiateur.
J'utilise actuellement une façade pour encapsuler la méthode de récupération des informations de configuration, par exemple. App.Config, paramètre utilisateur stocké dans SQL, informations d'assemblage, etc., et un médiateur pour la navigation entre différents formulaires Windows.
Cependant, la plupart des sites soulignent que le médiateur "ajoute une fonctionnalité". Que veulent-ils dire par là? Comment le médiateur ajoute-t-il des fonctionnalités?
... la plupart des sites soulignent que le médiateur "ajoute des fonctionnalités" ...
La façade expose uniquement les fonctionnalités existantes sous un angle différent.
La fonctionnalité médiateur "ajoute", car elle combine différentes fonctionnalités existantes pour en créer une nouvelle.
Prenons l'exemple suivant:
Vous avez un système de journalisation. À partir de ce système de journalisation, vous pouvez vous connecter à un fichier, à un socket ou à une base de données.
En utilisant le modèle de conception de façade, vous "masquez" toutes les relations des fonctionnalités existantes derrière une "interface" unique, celle exposée par la façade.
Code client:
Logger logger = new Logger();
logger.initLogger("someLogger");
logger.debug("message");
L'implémentation peut impliquer l'interaction de nombreux objets. Mais à la fin, la fonctionnalité existe déjà. La méthode "debug" est probablement implémentée comme suit:
La mise en oeuvre:
class Logger {
private LoggerImpl internalLogger;
private LoggerManager manager;
public void initLogger( String loggerName ) {
this.internalLogger = manager.getLogger( loggerName );
}
public void debug( String message ) {
this.internalLogger.debug( message );
}
}
La fonctionnalité existe déjà. La façade ne le cache que. Dans ce cas hypothétique, LoggerManager gère la création du journal approprié, et LoggerImpl est un objet privé de package doté de la méthode "debug". De cette manière, la façade n’ajoute pas de fonctionnalité, elle se contente de déléguer à certains objets existants.
D'autre part, le médiateur ajoute la nouvelle fonctionnalité en combinant différents objets.
Même code client:
Logger logger = new Logger();
logger.initLogger("someLogger");
logger.debug("message");
La mise en oeuvre:
class Logger {
private Java.io.PrintStream out;
private Java.net.Socket client;
private Java.sql.Connection dbConnection;
private String loggerName;
public void initLogger( String loggerName ) {
this.loggerName = loggerName;
if ( loggerName == "someLogger" ) {
out = new PrintStream( new File("app.log"));
} else if ( loggerName == "serverLog" ) {
client = new Socket("127.0.0.1", 1234 );
} else if( loggerName == "dblog") {
dbConnection = Class.forName()... .
}
}
public void debug( String message ) {
if ( loggerName == "someLogger" ) {
out.println( message );
} else if ( loggerName == "serverLog" ) {
ObjectOutputStrewam oos =
new ObjectOutputStrewam( client.getOutputStream());
oos.writeObject( message );
} else if( loggerName == "dblog") {
Pstmt pstmt = dbConnection.prepareStatment( LOG_SQL );
pstmt.setParameter(1, message );
pstmt.executeUpdate();
dbConnection.commit();
}
}
}
Dans ce code, le médiateur est celui qui contient la logique applicative pour créer le "canal" approprié pour la journalisation et pour créer la journalisation dans ce canal. Le médiateur "crée" la fonctionnalité.
Bien sûr, il y a de meilleures façons de mettre en œuvre cela en utilisant le polymorphisme, mais le point ici est de montrer comment le médiateur "ajoute" de nouvelles fonctionnalités en combinant des fonctionnalités existantes (dans mon exemple ne s'est pas montré très désolé) mais imaginons le médiateur, lisez à partir de la base de données, l'hôte distant où se connecter, puis crée un client et écrit enfin le message de journal dans le flux d'impression de ce client. De cette façon, le médiateur serait "médiateur" entre les différents objets.
Enfin, le façade est un motif structurel, c'est-à-dire qu'il décrit la composition des objets, tandis que le médiateur est un comportement, c'est-à-dire qu'il décrit la manière dont les objets interagissent.
J'espère que ça aide.
J'utilise médiateur pour ajouter une fonctionnalité de fichier journal.
Cela fonctionne comme ceci:
- Obj A dit au médiateur qu'il doit faire quelque chose.
- Le médiateur envoie le message à divers objets client.
- Obj B fait ce dont Obj A a besoin et renvoie un message approprié via le médiateur.
- Pendant ce temps, Obj C reçoit également les deux messages du médiateur et enregistre les résultats. De cette façon, nous pouvons obtenir des statistiques sur les utilisateurs à partir des fichiers journaux.
- Obj D pourrait également être un vérificateur d'erreurs. Ainsi, si Obj B répond que la requête de Obj A est impossible, Obj D pourrait être la chose qui le signale à l'utilisateur. Les erreurs peuvent maintenant être consignées dans un fichier différent de celui de l'activité habituelle et pourraient utiliser un autre moyen pour se comporter (en émettant un bip, etc.) avec lequel Obj A ne devrait pas vraiment se préoccuper.
sous les motifs associés, gof dit: Facade (185) se distingue de Mediator en ce qu’il abstrait un sous-système d’objets pour fournir une interface plus pratique. Son protocole est unidirectionnel. c'est-à-dire que les objets de façade font des demandes aux classes de sous-système mais pas l'inverse. En revanche, Mediator active le comportement coopératif que les objets collègues ne fournissent pas ou ne peuvent pas fournir, et le protocole est multidirectionnel.
Prenons une simple analogie:
Façade: comme un parking, sur appel
parkingLot.Out(car1);
mab be une simple chaîne fonctionne:
{
car1.StartEngin();
attendant.charge();
car1.driverOut();
}
Médiateur: comme un feu de circulation.
Il y a des interactions entre la lumière et la voiture,
et les voitures sont contrôlées par son état.
Je pense que c’est peut-être le le médiateur “ajoute une fonctionnalité”
Et à propos de la définition:
Type de façade: Structural
Type de médiateur: Comportemental
façade plus préoccupée par les composants étaient contenus dans l'interface unifiée ,
et le médiateur concerne comment un ensemble d'objets interagir .
Je pensais que la distinction était directionnelle: la façade est une communication à sens unique entre le client et la façade; Le médiateur peut être une conversation à double sens, avec des messages échangés entre le client et le médiateur.
Dans le livre "Design Patterns" (Modèles de conception), la clé du modèle Mediator est décrite comme suit:
En d'autres termes, un objet médiateur est le seul superobjet qui connaît tous les autres objets d'un groupe d'objets en collaboration et la manière dont ils doivent interagir les uns avec les autres. Tous les autres objets doivent interagir avec l'objet médiateur au lieu de l'autre.
En revanche, une façade est une "interface unifiée" pour un ensemble d'interfaces d'un sous-système - destiné à être utilisé par les utilisateurs du sous-système - et non parmi les composants du sous-système.
Vous pouvez trouver des détails sur le motif de façade dans cette question SE:
Quel est le modèle de conception de façade?
Facade fournit une interface simple et unifiée aux systèmes complexes.
Un exemple concret (cleartrip flight + booking d'hôtel) est disponible dans cet article:
Quel est le modèle de conception de façade?
Mediator pattern: définit un objet qui encapsule la manière dont un ensemble d'objets interagit. Le médiateur favorise le couplage lâche en empêchant les objets de se référer explicitement les uns aux autres, et vous permet de faire varier leur interaction de manière indépendante.
Un exemple concret de topologie de réseau Mesh a été fourni dans la question SE suivante:
Modèles de conception orientés objet Mediator Vs Observer
En ce qui concerne votre requête sur le médiateur ajoute la responsabilité:
Facade fournit uniquement une interface avec les sous-systèmes existants. Les sous-systèmes existants ne connaissent pas la classe de façade elle-même.
Le médiateur connaît les objets collègues. Il permet la communication entre différents collègues. Dans l'exemple que j'ai cité dans la question liée, ConcreteMediator (NetworkMediator) envoie des notifications de registre et d'événement de suppression d'un collègue à tous les autres collègues.
Les deux imposent une sorte de politique à un autre groupe d'objets. Façade impose la politique d'en haut, et Mediator impose la politique d'en bas. L'utilisation de Facade est visible et contraignante, tandis que l'utilisation de Mediator est invisible et habilitant.
Le motif Facade est utilisé lorsque vous souhaitez fournir une interface simple et spécifique à un groupe d'objets ayant une interface complexe et générale.
Le modèle Mediator impose également une politique. Cependant, alors que Facade a imposé sa politique de manière visible et contraignante, Mediator impose sa politique de manière cachée et sans contrainte.
Développement logiciel agile, principes, modèles et pratiques Robert C. Martin.