Mediator design pattern
Ou comment éviter le code Spaghetti
En programmation, il peut être difficile de s’approprier un code étranger. Plus un code est clair, succinct et direct, plus il est facile de le partager, et ainsi améliorer, le travail de groupe, la relecture et le confort de codage. Mais, le codage renferme nombre de problèmes, certains récurrents, auxquels tout un chacun sera tôt ou tard confronté. C’est pourquoi, il apparaît en 1994, la notion de design pattern, ou patron de conception, dans le livre Design Patterns-Elements of Reusable Object-Oriented Software écrit par Erich Gamma, Richard Helm, Ralph Johnson et Jhon Vlissides, surnommés « Gang of Four », dont le but est de relever ces problèmes récurrents, et de proposer des modèles de solutions, permettant de faciliter l’écriture de code et d’augmenter ainsi la rapidité de création.Le Mediator design pattern s’inscrit dans la lignée des design pattern comportementaux, qui sont des patrons de solutions standards répondant à certains problèmes courants de relations et comportements entre sous-programmes, rencontrés lors de la conception de logiciels. Le mediator design pattern s’applique aux problèmes de communications et d’appels imbriqués.
Lors de la création d’un logiciel comportant plusieurs sous-codes, il existe des relations entre les différents objets. Qu’il s’agisse de récupérer des variables ou d’utiliser des méthodes appartenant à une autre sous-entité, l’implémentation peut devenir rapidement lourde et confuse : il apparaît ce qui est communément appelé un code spaghetti. Fouillis, difficilement lisible, et très complexe, le code devient incompréhensible et utilise de nombreux sauts, exceptions et gestions d’événement en tout genre, un véritable feu d’artifice. D’autres programmateurs ne peuvent se l’approprier efficacement. Bien qu’augmenter la fragmentation du code peut sembler être efficace, il faut faire attention à la multiplication des interconnections.
On peut illustrer le spaghetti code par la phrase suivante :
« Est-ce que toi veux effectuer lecture de mon programme que j’ai écrit ? »
Le but est donc de transformer notre exemple précédent en ce qui suit :
« Veux-tu lire mon code ? »
Ainsi, le Mediator design pattern définit une entité s‘inscrivant comme chaperon des communications. En effet, une solution permettant de limiter les interconnections réside dans la définition d’un objet encapsulant comment un certain nombre d’autres objets interagissent entre eux. On évite ainsi les appels explicites. Le médiateur gère dès lors toutes les communications, il contrôle et coordonne les interactions de ses clients.
On peut illustrer la théorie du médiateur par une tour de contrôle d’aéroport. Les avions ne sont pas en communication entre eux, mais avec la tour. Ainsi, les informations sont centralisées, et le centre de contrôle peut coordonner les différents atterrissages et décollages.
Voici ci-dessous un exemple d’implémentation en java d’un médiateur :
import java.util.Date;
public class ChatRoom {
public static void showMessage(User user, String message){System.out.println(new Date().toString() + " [" + user.getName() + "] : " + message);}}
La class ChatRoom va ici être notre médiateur. Elle comprend une méthode permettant de mettre en forme le message d’un utilisateur et de le faire apparaître dans un terminal sous la forme :
Date [nom_User] : message
public class User {
private String name;
public String getName() {
return name;
}public void setName(String name) {
this.name = name;
}public User(String name){
this.name = name;
}public void sendMessage(String message){
ChatRoom.showMessage(this,message);
}}
Ici, on implémente le constructeur de User, et on lui attribue une fonction sendMessage qui la relie à notre médiateur, ici ChatRoom.
public class MediatorPatternDemo {
public static void main(String[] args) {User robert = new User("Robert");
User john = new User("John");robert.sendMessage("Hi! John!");
john.sendMessage("Hello! Robert!");}}
Pour finir, on implémente la classe principale, soit le main. A l’intérieur, on définit deux utilisateurs User, robert et john. Chacun d’eux envoient un message avec la commander sendMessage, définie dans le constructeur User. Mais cette commande passe par le ChatRoom, et c’est là que se crée le médiateur. ChatRoom est la seule entité à avoir accès aux messages de chacun. Elle les met en forme, et les affiche sur le terminal, comme vu plus haut. Il n’y a pas d’autres instances qui gère la communication et l’affichage, ce qui simplifie le code, et évite de nombreux détours.
Sources :
https://sourcemaking.com/design_patterns/mediator
https://en.wikipedia.org/wiki/Mediator_pattern
https://www.tutorialspoint.com/design_pattern/mediator_pattern.htm
https://prezi.com/i48qh74ra7wy/mediator-design-pattern/
Design Patterns: Elements of Reusable Object-Oriented Software, Erich GAMMA, Richard HELM, Ralph JOHNSON, Jhon VLISSIDES (1994)
