[Plugin] Eviter la dépendance circulaire - Design Pattern Observer

Bonjour,

Je travaille sur un plugin Eclipse que j'ai décomposé en deux : un plugin pour les classes définissant la logique de l'application et un plugin pour les classes graphiques.

Seul le plugin graphique peut faire appel à des classes faisant partie du plugin métier, sinon j'aurais un problème de dépendance circulaire. Actuellement j'ai un problème puisque une de mes classes métiers (plugin métier) fait appel à une méthode d'une classe graphique (plugin graphique). La méthode appelée sert à afficher une boite de dialogue pour l'utilisateur.

J'ai pensé à implémenter le patron de conception Observer (dans mon cas, la classe métier est l'objet observé et la classe graphique est l'objet observable qui attend une notification afin d'afficher la boite de dialogue) mais ça ne résout pas le problème étant donné que lorsque je vais enregistrer les écouteurs de ma classe observer (la classe métier), j'aurais besoin d'une instance de la classe observateur (la classe graphique) et par conséquent je tombe aussi dans une dépendance circulaire.

Quelqu'un saurait-il m'indiquer comment résoudre ce problème ?

Merci pour vos réponses.

Salut,

Au lieu de parler de partie "graphique", on peut parler de partie "interface graphique utilisateur" (GUI), ce qui comprend la partir graphique (l'affichage), mais également les actions, les handlers, etc. La partie métier constitue un ensemble d'opérations que les handlers orchestent. Après tout dépend de ce que tu as à faire exactement.

1) cas 1 : afficher un résultat

Code:

---

1 2	calculer un résultat // partie métier afficher le résultat / partie GUI

---

Là, le handler est facile : c'est directement cet enchainement (simplement "calculer un résultat" est fait par des classes qui sont dans le plugin métier, et on utilise une classe qui représente le résultat, créé dans le plugin métier, mais utilisable dans le plugin de GUI)

2) cas 2 : saisir des paramètres

Code:

---

1 2	saisir des paramètres // partie GUI manipuler les paramètres pour faire quelque chose // partie métier

---

Le handler est facile aussi : c'est le même principe que le cas 1. La classe qui représente les paramètres a le même statut que la classe qui représente le résulat dans le cas 1.

3) le mélange de 1 et 2

Code:

---

1 2 3

saisir des paramètres // partie GUI manipuler les paramètres pour élaborer un résultat // partie métier afficher le résultat

---

Pas de difficulté non plus : c'est le même principe que 1 et 2.

4) une répétion de 3 dans un même processus métier

Là, ça pourrait être aussi simple que le 3, avec éventuellement une classe unique de paramètres/résultats pour communiquer entre la partie métier et la partie UI, mais il est évident qu'on va multiplier artificiellement les méthodes : le processus métier va être découpé en petites méthodes qui seront appelées par le handler. En général, un processus métier peut et doit être découpé en méthode élémentaire, ce qui simplifie souvent la maintenance, si ce n'est que la relecture. Mais il est vrai que ça peut avoir ses limites : on peut avoir une méthode métier qui modifie un objet qui a 100 propriétés par exemple. Difficile de découper la méthode d'affectation de ces propriétés en méthodes, sans créé des méthodes artificielles, où alors il faut soit faire de la réflexion (pour l'appel des mutateurs de l'objet), ou concervoir l'objet avec des mutateurs du genre setProperty(String name, T value), par exemple). Mais c'est là un cas particulier. Et il peut y en avoir beaucoup, ce qui fait qu'on peut se retrouver à complexifier artificiellement la méthode métier juste à cause du fait que la partie UI est indépendante.

J'ai dans mon application plusieurs cas similaires. L'un des cas les plus démonstratifs est pourtant un peu différent : j'ai un plugin technique (non métier), qui réalise un système de checkout/checkin sans UI Eclipse :

Code:

---

1 2 3 4

poser un verrou checkout sur un objet du serveur télécharger un fichier représentant l'objet sur le poste ouvrir le fichier dans une application externe du poste lancer un callback qui attend que le fichier soit libéré par l'application locale pour le renvoyer au serveur et libérer le verrou checkout

---

D'autre part, j'ai un autre plugin qui vient greffer à ce système une GUI sous forme de palette flottante qui permet d'interagir avec le fichier ouvert dans l'application. Mais cette palette flottante doit également interargir avec le plugin de checkout. Par exemple, lorsque le fichier est renvoyée au serveur, une barre de progression est affichée, et les actions disponibles dans la palette doivent se désactiver. En plus, le plugin de la palette prend le contrôle sur le système de callback, car la palette non seulement communique avec l'application externe, mais également à des fonctionnalités qu'on ne peut faire que dans l'application externe quand on a pas de palette, comme libérer le fichier par exemple.
Comme le plugin de palette peut être désactivé (voir ne pas être installé), le plugin de checkout doit être autonome, mais déléguer certains de ses traitements liés à la GUI à la palette quand celle-ci est présente et activée.

Pour réaliser cette interaction, j'ai mis en place 2 ensembles de classes :

• Des écouteurs d'évenements (donc quelque chose du type observateur/observable) : la palette s'enregistre comme écouteur du plugin de checkout pour réagir aux changements d'état. Par exemple, la barre de progression de renvoi au serveur est gérée par ce système : la palette l'affiche, mais le plugin de checkout gère la progression (donne la taille totale, fait progresser le compteur d'octets envoyés, modifier les étapes qui permettent d'avoir des messages détaillés sur l'étape en cours, etc...). Il n'y a aucune référence à l'UI dans l'écouteur comme dans l'évenement, comme dans la partie qui soulèvent les évenements, mais il y a des références abstraites à la notion d'UI (comme les messages d'étapes de progression, par exemple).
• Pour le reste, j'utilise une interface de callbacks. L'interface est définie dans le plugin technique. Le plugin technique a une implémentation concrète de cette interface et la palette a sa propre implémentation concrète qui redéfinit certains comportements, et le plugin de palette remplace simplement le composant du plugin technique par le sien au démarrage (et le retire lorsqu'il s'arrête). Ainsi, quand une méthode du plugin de checkout est exécutée, elle appelle des méthodes de l'interface de callbacks, et selon, que la palette ait ou non installé son composant de callbacks, on appelle la version sans UI par défaut, ou la version avec GUI. L'interface de callbacks ne fait jamais directement référence à la GUI, mais à une abstraction de l'UI. Par exemple, il y a une fonction annuler dans le plugin de checkout, qui permet simplement de libérer le verrou et de supprimer le fichier local sans le renvoyer. La fonction annuler est appelée via un handler configuré dans une extension qui se trouve dans un troisième plugin, dans lequel on configure tous les actions et menus de la fonctionnalité de checkout. Lorsque le plugin de palette est activé, un dialogue de confirmation est affiché à l'utilisateur : l'interface de plugin à une méthode canCancel(MonObject) qui dans le plugin de checkout teste si l'objet est annulable (qui va dépendre du type de fichier et de l'interaction possible qu'il y a avec l'application externe, et que je paramètre par un point d'extension), et dans l'implémentation propre au plugin de palette, on affiche un message de confirmation dans lequel l'utilisateur peut "annuler son annulation".