Dans cette séance, on va s’intéresser à aux design patterns :

• Observer (Observateur)

• Visitor (Visiteur)

La problématique :

Dans la séance n°3, on avait prévu le diagramme de classes suivant pour modéliser le jeu de rôles :

La classe GUI a pour responsabilité d’afficher l’espace de jeu visible. À cet effet, elle peut rafraîchir souvent cet affichage pour être sûre de tenir compte des déplacements des ennemis (qui deviennent alors visibles). De même, lorsque le joueur combat un ennemi, ce dernier peut mourir et nécessiter un réaffichage. En rafraichissant suffisamment souvent la fenêtre, on peut faire en sorte que le jeu soit fluide. Une autre alternative pourrait être que, lorsque les ennemis se déplacent ou qu’ils combattent, ils en informent GUI, de manière à ce que les rafraichissements n’aient lieu que quand on en a besoin. Mettre en place un tel système de notification est précisément le rôle du design pattern Observer.

La solution apportée par Observer :

La solution apportée par le design pattern Observer peut être décrit grâce au diagramme UML suivant :

Concrètement, pour notre jeu de rôles, le Publisher est ÉtatJeu et le ConcreteSubscriber est la classe GUI.

En Java, cela donnerait un code similaire à :

public interface Subscriber {
  public void update(String notif);
}

public class GUI implements Subscriber {
  public GUI() {
    System.out.println("construction de GUI");
  }

  @Override
  public void update(String message) {
    System.out.println("GUI reçoit le message " + message);
  }
}

import fr.polytech.aco.MyArray;

public class EtatJeu {
  private MyArray<Subscriber> subscribers;

  public EtatJeu() {
    this.subscribers = new MyArray<>(10);
  }

  public void subscribe(Subscriber subscriber) {
    subscribers.pushBack(subscriber);
  }

  public void unsubscribe(Subscriber subscriber) {
    subscribers.remove(subscriber);
  }

  public void notifySubscribers() {
    for (var subscriber: subscribers)
      subscriber.update("Notification");
  }

  public static void main(String[] args) {
    var etatJeu = new EtatJeu();
    var gui1 = new GUI();
    var gui2 = new GUI();

    etatJeu.subscribe(gui1);
    etatJeu.subscribe(gui2);
    etatJeu.notifySubscribers();
  }
}

Avantages et inconvénients :

Avantages :

• Le principe Ouvert/Fermé est respecté puisque le Publisher ne connaît ses abonnés qu’au travers de l’interface Subscriber. On peut également assurer cela côté Subscriber en faisant en sorte que Publisher implémente une interface InterPublisher qui est la seule connue par les Subscribers.

• Le design pattern évite que l’on ait à mettre en place un timer pour que les Subscribers soient au courant des modifications du Publisher, ou que le Publisher ait explicitement à appeler des méthodes de plein de Subscribers pour leur envoyer des informations.

• Le Publisher peut envoyer des notifications à un nombre arbitraire de Subscribers.

Inconvénients :

• On ne maîtrise pas forcément l’ordre dans lequel les Subscribers sont notifiés, ce qui peut poser des problèmes dans certaines applications.

La problématique :

Un de vos amis, qui joue souvent aux jeux vidéos, a joué à votre jeu de rôle. Il le trouve super mais il dit que, dans les jeux vidéos, on peut souvent sauvegarder le jeu en cours de partie et c’est une fonctionnalité intéressante car elle permet de ne pas avoir à repartir « from scratch » quand notre personnage meurt. No problemo, il suffit de rajouter une méthode sauvegardeJeu() dans la class ÉtatJeu. Mais si on écrit tout le code de sauvegarde dans cette méthode, on va violer le principe Ouvert/Fermé parce que, si on rajoute de nouveaux types d'Ennemis, il faudra modifier cette méthode. Qu’à cela ne tienne, il suffit de rajouter une méthode sauvegardeEnnemi() dans chacune des classes d'Ennemi. Mais, là, on viole le principe de responsabilité unique : un Ennemi est là pour se promener dans le jeu et vous attaquer, pas pour interagir avec le système de fichiers. C’est d’autant plus vrai si, une fois les méthodes de sauvegarde sur fichier écrites, votre ami vous dit que « c’est has been d’écrire sur fichier, maintenant tout se passe sur le cloud ». Du coup, il faut rajouter de nouvelles méthodes de sauvegarde dans vos Ennemis. C’est bof. Heureusement, le design pattern Visitor est là pour vous sauver.

La solution apportée par Visitor :

La première idée qui vient à l’esprit est de créer une nouvelle classe SauvegardeJeu (c’est notre Visiteur) qui contiendra des méthodes de sauvegarde, une par type d'Ennemi. Ensuite, pour chaque Ennemi, SauvegardeJeu() appelle la méthode de sauvegarde spécifique à l'Ennemi. Cela donnerait par exemple :

public class EtatJeu {
  private MyArray<Ennemi> ennemis;

  public EtatJeu() {
    this.ennemis = new MyArray<>(10);
  }

  public void addGobelin() {
    this.ennemis.pushBack(new Gobelin());
  }

  public void addOrc() {
    this.ennemis.pushBack(new Orc());
  }

  public MyArray<Ennemi> getEnnemis() {
    return this.ennemis;
  }
}

public class SauvegardeJeu {
  public void sauvegardeJeu(EtatJeu etatJeu) {
    for (var ennemi : etatJeu.getEnnemis()) {
      this.sauvegardeEnnemi(ennemi);
    }
  }

  public void sauvegardeEnnemi(Gobelin gobelin) {
    System.out.println("sauvegarde d'un gobelin");
  }

  public void sauvegardeEnnemi(Orc orc) {
    System.out.println("sauvegarde d'un orc");
  }
}

Sur la ligne soulignée en jaune, par polymorphisme, on appelle la méthode sauvegardeEnnemi() correspondant à l’ennemi passé en argument et le tour est joué… Heu… Non, en fait, cela ne va pas fonctionner. En effet, sur la ligne en jaune, tout ce que connaît la classe sauvegardeJeu, c’est que ennemi est de type Ennemi. Et, à la compilation, c’est tout ce que l’on connaît. Le compilateur ne pourra donc pas choisir la bonne méthode sauvegardeEnnemi(). D’ailleurs, vous obtiendrez une erreur de compilation. Pour pallier cela, on va demander à l'Ennemi d’appeler la méthode de sauvegarde qui va bien : lui sait s’il est un Orc ou un Gobelin et il pourra donc indiquer au compilateur quelle méthode de sauvegarde doit être appelée. Cette technique s’appelle le double dispatch (double répartition en français). Cela nous donne le code ci-dessous. D’abord la classe de sauvegarde (le visiteur) :

public interface Visiteur {
  public void visiter(Orc ennemi);
  public void visiter(Gobelin ennemi);
  public void visiter(BandeEnnemis ennemi);
  public void visiter(Boss ennemi);
  public void visiter(Hulkise ennemi);
}

public class SauvegardeJeu implements Visiteur {
  public void sauvegardeJeu(EtatJeu etatJeu) {
    for (var ennemi : etatJeu.getEnnemis()) {
      ennemi.accepter(this);
    }
  }

  public void visiter(Gobelin gobelin) {
    System.out.println("sauvegarde d'un gobelin");
  }

  public void visiter(Orc orc) {
    System.out.println("sauvegarde d'un orc");
  }

  public void visiter(Boss boss) {
    System.out.println("sauvegarde d'un boss");
  }

  public void visiter(Hulkise hulkise) {
    System.out.println("sauvegarde d'un hulkisé");
  }

  public void visiter(BandeEnnemis bande) {
    for (var ennemi : bande) {
      ennemi.accepter(this);
    }
  }
}

Ensuite, on crée une interface Visitable que chaque Ennemi implémente :

public interface Visitable {
  public void accepter(Visiteur visiteur);
}

public interface Ennemi extends Visitable {
  public String attaquer();
}

public class Orc implements Ennemi {
  public String attaquer() {
    return "attaque d'un Orc";
  }

  public void accepter(Visiteur visiteur) {
    visiteur.visiter(this);
  }
}

Enfin, la classe ÉtatJeu qui déclenche la sauvegarde :

import fr.polytech.aco.MyArray;

public class EtatJeu {
  private MyArray<Ennemi> ennemis;

  public EtatJeu() {
    this.ennemis = new MyArray<>(10);
  }

  public void addEnnemi(Ennemi ennemi) {
      this.ennemis.pushBack(ennemi);
  }

  public MyArray<Ennemi> getEnnemis() {
    return this.ennemis;
  }


  public static void main(String[] args) {
    BandeEnnemis bande1 = new BandeEnnemis();
    bande1.addEnnemi(new Boss(new Orc()));
    bande1.addEnnemi(new Gobelin());

    BandeEnnemis bande2 = new BandeEnnemis();
    bande2.addEnnemi(new Gobelin());
    bande2.addEnnemi(bande1);

    var etatJeu = new EtatJeu();
    etatJeu.addEnnemi(new Orc());
    etatJeu.addEnnemi(bande1);
    etatJeu.addEnnemi(bande2);

    var sauvegarde = new SauvegardeJeu();
    sauvegarde.sauvegardeJeu(etatJeu);
  }
}

Il est à noter que, dans le code ci-dessus, pour simplifier, ÉtatJeu contient une méthode getEnnemis() qui permet à SauvegardeJeu de récupérer la liste des Ennemis à sauvegarder. Il vaudrait mieux fournir un itérateur permettant de parcourir la liste des Ennemis. Cela permettrait en effet de ne pas exposer la structure de données MyArray, de manière à préserver le principe Ouvert/Fermé (si on remplace cette structure par un ArrayList par exemple, aucune autre classe n’est impactée).

En termes de diagramme de classes UML, cela revient au diagramme ci-dessous. Le point de départ est la classe Client (la main() d'ÉtatJeu) qui demande au VisiteurConcret (la classe SauvegardeJeu) de réaliser une action (sauvegardeJeu) sur notre ElémentVisitable (ÉtatJeu). Celui-ci demande alors à l'ElémentVisitable d’accepter le Visiteur. L’acceptation consiste à appeler la méthode visiter() du visiteur qui prend en paramètre chaque type concret d”ElémentVisitable. La méthode visiter() réalise alors le travail qu’on demandait au VisiteurConcret de réaliser.

Avantages et inconvénients :

Avantages :

• Le principe Ouvert/Fermé des éléments visitables est respecté : si l’on rajoute de nouvelles méthodes de sauvegarde, on n’aura pas à modifier ces éléments.

• Le principe de Responsabilité Unique est respecté puisque le visiteur n’a qu’une tâche à réaliser et celle-ci n’a pas besoin d’être définie dans les éléments visitables.

• Il est aisé de rajouter de multiples fonctionnalités à un élément visitable : une fois que celui-ci implémente l’interface visitable, on peut lui plugger n’importe quel visiteur.

Inconvénients :

• Les visiteurs ne respectent pas le principe Ouvert/Fermé : si vous rajoutez de nouveaux types d’ennemis, ils doivent être mis à jour.

• On peut être amené à exposer, au moins en partie, le contenu des classes visitables.