Discussion :

[Happpy]

Bonjour,

je me demande comment sont gérés les plug-in en général, c'est-à-dire, comment est géré le fait qu'on puisse étendre un logiciel, et que tout s'articule correctement ?

On peut prendre l'exemple des ERP, où on peut décider du jour au lendemain d'acheter un autre module, alors que tous les modules sont gérés dans la même application, la même interface, je crois.

C'est la même question que pour la mise à jour d'une application.

Comment tout cela se passe en général, au niveau code, etc., peu importe le langage de programmation, mais prenons l'exemple du langage Java par exemple ?

Merci d'avance

[hwoarang]

Il y a 2 concepts tres différents ici. Dans un programme ou tu peux acheter tout ou seulement une partie des fonctionnalités, la gestion se fait souvent au niveau des droits qui vont afficher les ecrans auquel tu as souscris et pas les autres (surtout si c'est une appli web). Il n'y a pas vraiment de plugin mais plutot des menus qui sont peuplés en fonction des droits.

En ce qui concerne les plugins, qui permettent à une application de laisser les utilisateurs ajouter des fonctionnalités, comme le logiciel Eclipse, c'est plus compliqué.
Tu peux par exemple definir une interface que tes plugins devront implementer (en fonction de ce à quoi ils servent) et charger les plugins au lancement de l'application.
Un exemple:
http://vincentlaine.developpez.com/t.../java/plugins/

[Happpy]

Ah les droits, je n'y avais pas pensé bêtement ! Oui...

Je vais lire le cours du lien que tu m'as donné, je ne peux pas le faire tout de suite mais je ferais au plus vite ^^

Merci !

[Mickael_Istria]

En general, les systemes modulaires reposent sur:

1. un systeme de detection et/ou d'installation de modules. En Java, OSGi fait ca: l'appli tourne dans un conteneur (le main est le conteneur, pas ton programme) qui est capable de recevoir des commandes pour ajouter/enlever, activer/desactiver un module. Ces conteneurs peuvent souvent etre configures pour charger tous les modules qu'il trouve dans un dossier par defaut.

2.un systeme d'extension de "comportement" En general, la librarie ou le conteneur qui gere l'extensibilite (OSGi aussi a ca en Java, c'est Declarative Services; dans Eclipse il y a aussi le systeme de points d'extension par plugin.xml) decide d'une convention pour declarer les extensions. Typiquement, le conteneur dit "Je vais regarder le fichier `toto` de chaque module installe et pour chacun d'eux je vais faire ce qu'ils declarent dans ce fichier". Du coup, les modules declarent leurs extensions suivant la convention/specification de le container.
Dans OSGi, c'est le MANIFEST.MF et d'autres fichiers lies depuis le MANIFEST.MF comme OSGI-INF/component.xml qui sont lus et qui disent a OSGi que telle ou telle extension est disponible. Un morceau de code "metier" consomme ensuite ces extensions. OSGi c'est un bon modele en la matiere, et il y a pas mal de presentations, dont certaines tres bien faites, qui expliquent mieux la modularite et l'extensibilte en general, et qui ensuite montrent comment OSGi fait ca.
Dans Eclipse, c'est le fichier plugin.xml qui decrit les extensions (par exemple les menus) et le code d'Eclipse lui-meme lit ces extensions pour savoir quels menus afficher. Le modele Eclipse marche bien aussi, mais il est moins "beau" que celui d'OSGi, donc pour t'initier, prends OSGi en reference plutot.
Une autre approche, compatible avec celles du dessus, consiste aussi maintenant a passer par des annotations plutot que des fichiers de declarations. Du coup, quand le conteneur va charger le module, en plus ou au lieu de lire un fichier specifique qui decrit les extensions, il peut aussi introspecter le code pour trouver des annotations qui definissent les extensions). En gros, un peu comme de l'injection de dependance (CDI, Spring) mais en plus dynamique, puisque tes modules et extensions peuvent etre dynamiquement installes/desinstalles.

Bon, c'est une reponse vite-fait sur un sujet quand meme tres riche. Si tu veux aller plus loin, a mon avis, jette un oeil a comment marche OSGi, c'est vraiment de la belle modularite, a la fois au niveau theorique et pratique.