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
10
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
10
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
38
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.
Afficher les 8 commentaires