GESTION DE MODULE (PLUGINS) - CHARGEMENT DYNAMIQUE

tmcuh Messages postés 458 Date d'inscription dimanche 22 décembre 2002 Statut Membre Dernière intervention 18 avril 2009 - 12 août 2005 à 17:27
Nikoui Messages postés 794 Date d'inscription vendredi 24 septembre 2004 Statut Membre Dernière intervention 19 août 2008 - 2 oct. 2007 à 11:08

Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/33177-gestion-de-module-plugins-chargement-dynamique

Nikoui Messages postés 794 Date d'inscription vendredi 24 septembre 2004 Statut Membre Dernière intervention 19 août 2008 13
2 oct. 2007 à 11:08

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
2 oct. 2007 à 10:26

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
30 sept. 2007 à 13:07

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 13
16 févr. 2006 à 11:43

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 Membre Dernière intervention 14 février 2014 37
22 août 2005 à 09:53

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.

tmcuh Messages postés 458 Date d'inscription dimanche 22 décembre 2002 Statut Membre Dernière intervention 18 avril 2009
12 août 2005 à 21:07

oki j'ai suivis, comment fait-tu pour récupéré tes plugin par dll?
Comment doit etre créer la composant utilisateur?
Cordialement,
laurent

Nikoui Messages postés 794 Date d'inscription vendredi 24 septembre 2004 Statut Membre Dernière intervention 19 août 2008 13
12 août 2005 à 20:28

Mais la c'est aussi le cas... L'exemple que j'ai mis pour les logs montre bien cela : je sais que j'aurai des modules de logs, mais je ne sais pas lesquels (texte? fichier? par réseau? par mail?)... De la même facon que winamp sait qu'il aura des modules de visualisation, des modules d'entrée, de sortie, etc... Mon exemple est basique mais le code permet justement de faire des plugins. Tu décris l'interface commune de tes plugins comme je l'ai fait pour le module de log, et ensuite tu peux ecrire librement tes plugins, c'est complètement transparent pour l'application qui chargera et utilisera tous les plugins trouvés au démarage - mais tu es forcément obligé de décrire l'interface de tes modules, pour pouvoir l'utiliser dans ton programme, de la même facon qu'un plugins winamp doit respecter une certaine interface pour être intégré a l'application

tmcuh Messages postés 458 Date d'inscription dimanche 22 décembre 2002 Statut Membre Dernière intervention 18 avril 2009
12 août 2005 à 17:27

he he l'idée est pas mauvaise. Cependant au vu de l'application je m'apperçoi que les modules doivent être connu à l'avance et seulement quand l'application se lance il test si elles existent. Il aurait été bien de faire un vrai plugin, celui dont on ne connait rien et qui se rajoute au prog. Un peu comme winamp; il donne des fonctions mais le programmeurs de winamp ne connais ni le futur de son application, ni les programmeurs qui vont venir greffer des plugins. D'où l'interet des plugin; toi c'est plutot des fonctions intégrer au programme qui vont se charger ou pas (suivant une licence par exemple).
En espérant voir une version plus évolué apparaitre, bonne prog.
10/10 pour l'idée

Discussions similaires

cahier des charges d'une application de gestion des stocks et achats classique

Génération d'un plan de chargement

cahier de charge de logiciel de gestion de stocks

gestion rendez vous+application open source

Réaliser une matrice avec Excel

Votre réponse

Discussions similaires