Collaboration d'ActiveX et design pattern Médiateur

Le modèle de conception "Médiateur" offre une solution originale pour faire collaborer des ActiveX ensemble, situés dans des conteneurs ActiveX n'appartenant pas nécessairement à la même application.
Dans ce modèle, la classe ayant le rôle de médiateur possède une référence de tous les objets devant participer à la réalisation d'une tâche et contient toute la logique du traitement. Cela évite que tous les objets se fassent référence les uns aux autres en complexifiant les traitements.

La mise en ouvre de ce modèle s'appuie ici sur des ActiveX qui sont des ActiveForm créés avec Delphi et utilisant des interfaces OLE automation. Mais je gage que le lecteur pourra réutiliser les principes exposés dans cet article avec son propre outil de développement et/ou d'autres technologies.
Si vous permettez à votre navigateur d'exécuter des ActiveX, vous pourrez aussi tester le résultat de cette mise en ouvre dans une page HTML. Pour cela, reportez vous à la rubrique Ressources à la fin de cet article.

Exposition du problème

Nous souhaitons offrir une interface utilisateur (UI) pour la saisie de nombres sous la forme d'un ActiveX présentant des touches numériques ; cette saisie sera reflétée par un ou plusieurs autres objets COM basés sur un autre ActiveX se contentant d'afficher ce qui aura été saisi.

Voici le diagramme de classes UML de ces ActiveX d'interface utilisateur implémentés dans l'OCX VposUI.ocx :

Les classes TFrmKbUI et TFrmDisplayUI sont les coclasses implémentant chacune une interface COM distincte. Par simplification, ces interfaces ne définissent qu'une seule méthode identique, MiseAJour, susceptibe d'être appelée par le médiateur pour demander au contrôle de se rafraîchir. A ce moment les ActiveX "DisplayUI" pourront interroger le médiateur pour connaître le nombre à afficher.

Le médiateur

Le médiateur est implémenté dans l'exécutable Vpos.exe comprenant un objet OLE automation, TCoVlp, par la classe TMediateur. Cette classe est définie avec le modèle Singleton, c'est-à-dire que l'on ne crée et n'utilise qu'une seule instance de cette classe.
L'objet automation TCoVlp, qui est invoqué par les ActiveX d'interface utilisateur, est chargé de faire le lien avec l'instance unique du médiateur.

Le diagramme de classes UML de Vpos.exe est présenté ci-dessous :

La classe TFrmVpos représente la fiche principale de l'application, que l'on peut choisir de montrer ou non. Elle peut servir à présenter des messages destinés au déboguage par exemple.

Le diagramme de séquence ci-dessous présente les principales étapes d'exécution, en partant de l'instanciation de l'ActiveX UI "clavier" dans un conteneur :

Test

Pour tester ce code, vous devez tout d'abord télécharger l'exécutable Vpos.exe (renfermant le médiateur), placé dans le fichier Vpos.zip. Dézippez-le pour ensuite exécuter "Vpos /regserver", ce qui enregistrera le serveur dans la base de registres de Windows (Vpos.exe se désinstalle tout d'abord en exécutant "Vpos /unregserver", puis en supprimant ce fichier).
Vpos.zip
Vous pouvez maintenant utiliser le lien ci-dessous vers une page HTML qui comprend les ActiveX de VposUI.ocx (votre navigateur doit autoriser l'exécution d'ActiveX sur votre machine) :
medt.html

Sommaire

Exposition du problème
Le médiateur
Test

Début