TUTORIEL

Evénements en JAVA

L'analyse de GreenJ par les fiches CRC a mis en évidence la nécessité d'un mécanisme informant le Générateur de tout changement intervenant dans une fiche, une classe, une instance, pour qu'il reporte éventuellement cette modification dans le code.
J'ai pensé alors programmer ce mécanisme, en créant un événement GreenJChange.
En l'absence de présentation de ce type de gestion dans les différents ouvrages dont je disposais personnellement, j'ai dû trouver de la documentation et des exemples sur le Web. Du fait de la fragmentation des informations, j'ai travaillé à comprendre les principes nécessaires, et je vous livre ici la présentation en résultant.

Principes

Le fonctionnement du système, tel que je le souhaite, semble correspondre aux cas résolus par le patron "Observateur" :

Description du patron "Observateur"

Le tout donne le schéma suivant :

schéma Sujet - Observateur

La séquence type d'un changement sera la suivante :
  1. le SUJET a été changé, via un des ses modificateurs
  2. sa méthode "notifier()" doit être alors exécutée par ce modificateur
  3. celle-ci exécute la méthode "actualiser()" de chaque OBSERVATEUR inscrit
  4. la méthode "actualiser()" de ce dernier effectue les traitements qui vont bien dans son cas

Avantages

Le SUJET n'a pas à connaître les méthodes de l'OBSERVATEUR. Le premier peut être dans un paquetage (objets Métier par exemple) n'ayant pas de visibilité sur celui du second (plugins ou IHM), du moment que ce dernier implante l'interface OBSERVATEUR du premier paquetage.
Le SUJET se contente d'envoyer une notification, à charge pour les OBSERVATEURs de traiter celle-ci ou non.

Inconvénients

Chaque OBSERVATEUR étant indépendant des autres (pas de connaissance mutuelle), ils peuvent déclencher une cascade de changements s'empilant à la suite.
L'ordre des notifications est fonction du seul ordre d'inscription de chacun des OBSERVATEURs.
A défaut d'arguments explicites dans la méthode "actualiser()", l'OBSERVATEUR n'a pas d'informations sur les changements du SUJET, et devra interroger ce dernier via ses méthodes publiques.

GreenJ et Observateur

Nous avons vu que les changements apportés par l'utilisateur aux schémas pouvaient être répercutés au code au moyen d'observateurs.
Comment celà va-t-il se traduire dans l'application ?

Paquetages et classes en jeu

Seuls les objets GreenJ (fiches, classes et instances) savent qu'ils ont changé : ils connaissent leur statut courant et ont seuls l'accès au code interne de leurs modificateurs. Les SUJETs seront donc les GreenJObject et leurs héritiers.

Puisque ceux-ci font partie du paquetage Métier Engine, l'interface décrivant les OBSERVATEURs, nommée IGreenJObjectObserver, sera incluse dans ce même paquetage.

Les OBSERVATEURs potentiels sont le Generator et l'Introspector, dans le paquetage Java (d'autres paquetages similaires pourront être conçus couvrant d'autres langages Objet).

Spécificité de GreenJ

L'utilisateur pouvant créer de nouveaux objets GreenJ dans les schémas, il faut inscrire le Generateur et l'Introspecteur auprès de ceux-ci dès leur création.