WTF ?

Dans le dernier article je présentais un gestionnaire d’événement. Pour résumer, celui-ci propose de réaliser des projets en se basant sur des relations cause->effet. Dans l’état actuel des choses, les effets entraînés par des causes (événements) sont contenus dans le code exécutable.

L’idée est maintenant de permettre à l’utilisateur d’un programme de modifier son comportement à l’aide de scripts interceptant les événements levés par le programme et exécutant des actions ayant des répercutions sur la suite de l’exécution du programme. De plus, ce mode de fonctionnement aura l’avantage de pouvoir rendre la conception du programme entièrement modulaire.

Beaucoup de logiciels emploient cette méthode : emacs par exemple, célèbre éditeur de texte avec l’utilisation de scripts en lisp pour la configuration ou le jeu World of Warcraft avec ses addons programmés en LUA.

Le dernier objectif enfin est de proposer une abstraction suffisamment forte pour rendre le fonctionnement compatible avec n’importe quel langage de script interfaçable avec C#.

Fonctionnement actuel

Le programmeur doit ajouter un observateur qui, lorsqu’il verra passer un événement correspondant au type d’événement observé déclenchera un effet (c’est à dire une procédure).
Puis il n’a plus qu’à lever des événements pour entraîner des effets.

EventManager.AddWatcher("Type d'événement observé", Effect.Create(ProcedureAppelée)[, condition]);
EventManager.RaiseEvent("Type d'événement à lever", );

Nouveau fonctionnement

L’actuel fonctionnement restera utilisable, et pourra coopérer avec celui-ci, permettant d’utiliser le moteur d’événement avec des effets codés en C# et/ou dans un langage de script compatible.

A la compilation, le développeur ne sait pas quels scripts seront implémentés par le futur utilisateur, ni leurs besoins, ni les événements qui lanceront l’exécution de ces scripts. Il ne peut donc pas relier des événements à des effets qui n’existent pas encore.
Toutes ces informations seront connues de l’utilisateur lorsqu’il écrira son script, il apparaît donc naturellement que ce sera à lui d’effectuer ces actions.

Un deuxième problème est présent. L’utilisateur aura la possibilité dans ses scripts de libérer des événements. Imaginons un utilisateur mal-intentionné, il pourrait libérer des événements internes au projet qui pourrait entraver son bon fonctionnement. Il faut donc laisser la possibilité au développeur du projet de créer des observateurs d’événements internes qui n’entraîneront aucun effet dans le cas où l’événement a été déclenché par un script (événement public).

 

Pour la question de la modularité, le principe suivant sera établi : les scripts seront classés en modules repérés par un nom et une version.

Par ailleurs, chaque module comportera :

  • Une fonction d’installation qui permettra d’ajouter effets et observateurs d’événements
  • Des propriétés constantes pour indiquer : le nom du module, sa version et d’éventuels prérequis (d’autres modules nécessaires à son fonctionnement)

Je garanti ainsi une encapsulation parfaite des différents modules, qui pourront malgré tout imposer la présence d’un ou plusieurs autres modules pour s’installer et communiquer à travers des événements interposer avec d’autres modules.