Gestion de module (plugins) - chargement dynamique

Soyez le premier à donner votre avis sur cette source.

Vue 16 729 fois - Téléchargée 1 341 fois

Description

Module Manager

La librairie ModuleManager permet la gestion de module, chargés dynamiquement en mémoire :

- Chargement des modules depuis les dll présentes dans un répertoire donné
- Permet aux classes utilisant cette librairie d'obtenir tous les modules d'un type particulier
- Permet aux classes utilisant cette librairie d'obtenir un module particulier d'un type particulier

Un exemple d'utilisation est fournie avec la création d'un type de module de log, et l'implémentation de deux modules de log : un module de log sur la console et un autre module de log dans un fichier.

Conclusion :


Projets contenus dans la solution :

Librarie principale :
- ModuleManager : librairie contenant le module manager

Librairie exemple :
- Logger : exemple de création d'un type de module (module de log)
- ConsoleLogger : exemple d'implémentation d'un module de log : log sur la console
- FileLogger : autre exemple d'implémentation d'un module de log : log dans un fichier trace.txt

Application de démonstration :
- TestApplication : Cette application fait appel au module manager pour récupérer la liste des modules de log disponible (dans le répertoire courant de l'application). Elle liste les modules de log trouvés. Elle permet de plus de saisir un message texte et de le logger (sur tous les modules de log chargés).

Important : l'application de démonstration charge les modules disponible dans son répertoire d'exécution. Pour tester l'application, ajouter ou retirer les modules de logs de ce répertoire (c'est à dire ConsoleLogger.dll et FileLogger.dll générés par les projets ci dessus).

Codes Sources

A voir également

Ajouter un commentaire

Commentaires

Nikoui
Messages postés
794
Date d'inscription
vendredi 24 septembre 2004
Statut
Membre
Dernière intervention
19 août 2008
7 -
Il est possible d'utiliser des interfaces à la place des abstract class, mais il faut en effet modifier le code que tu cites. En fait, de mémoire, le code en question teste si le module hérite bien de la classe abstratire "mère" : si tu utilise des interfaces, il faut le modifier pour qu'il vérifie que l'objet testé implémente l'interface de base.

Et d'ailleur je me demande si un simple test "is" ne suffit pas à gérer les deux cas (héritage d'une classe abstraite ou implémentation d'une interface).

Si tu tiens à utiliser des interfaces, je pourrai jeter un oeil sur le code un peu plus tard pour te donner les infos utiles.
godvicien
Messages postés
36
Date d'inscription
dimanche 23 janvier 2005
Statut
Membre
Dernière intervention
6 avril 2014
-
Arf ! Passé aux interfaces qui remplacent les abstract class ca ne fonctionne plus.

Ca bloque dans le skin manager au moment du getType/getTypes

Je repasse aux abstract class...
godvicien
Messages postés
36
Date d'inscription
dimanche 23 janvier 2005
Statut
Membre
Dernière intervention
6 avril 2014
-
Parfait ! Exactement ce qu'il me fallait pour le systeme de skin que je suis en train de mettre en place.

Un skin est une dll qui contient les winforms de l'IHM

Il ne me reste plus qu'a créer l'interface (mieux qu'une classe abstraite) de mes skins.

Le SkinManager m'en donnera la liste, et l'utilisateur aura le choix de sa skin...

10/10 par ce que le code est parfaitement documenté, et c'est rare !
Nikoui
Messages postés
794
Date d'inscription
vendredi 24 septembre 2004
Statut
Membre
Dernière intervention
19 août 2008
7 -
Tu as raison Sebmafate... Il n'y a ici aucune raison d'utiliser une classe abstraite au lieu d'une interface.

Pour la petite histoire, il s'agissait d'une version "simplifiée et nettoyée" d'une librairie un peu plus complexe... qui elle nécessitait une classe abstraite (avec du code dedant ;) ).

D'ailleur en regardant cette source, je me rend compte qu'elle a bien évoluée depuis... je devrais la mettre à jour sur le site. (par exemple, je n'utilise plus de propriété "Key", mais tout simplement le type de l'objet (ou le type implémenté dans le cas de plugins 'hierarchiques') pour identifier les plugins
sebmafate
Messages postés
4936
Date d'inscription
lundi 17 février 2003
Statut
Modérateur
Dernière intervention
14 février 2014
32 -
je regarde ta source avec un oeil critique car je suis moi-même en train de développer un système de plugins.
Je relève tout de même une erreur... tu as défini une classe abstraite Module, hors normalement une classe abstraite défini un ensemble de membres communs à X sous-classes. ces membres doivent-être implémentés, ce n'est pas le cas ici.
Ta classe abstraite est en réalité une interface, il serait donc plus logique que tu la type en conséquence.

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.