Tout à fait, faire une application modulable ce n'est pas vraiment compliqué, le seul travail est de bien spécifier les rôles de chaque module et donc celà force à faire une architecture carrée, et c'est pas plus mal. En gros :
- tu définis ce que ton module doit pouvoir faire et de quoi il a besoin pour le faire
- tu définis une interface pour que les fonctionnalités demandées puissent être accessible depuis ton application
- tu fais du chargement "dynamique" de module au lancement de l'appli pour trouver les modules, vérifier l'interface qu'ils implémentent, et zou tu les utilises.
- quelqu'un qui veut faire un module implémente l'interface correspondante et s'arrange pour que son code/exécutable/librairie soit accessible depuis ton application.
Exemple à l'arrache en français (je veux faire des modules pour supporter plusieurs format de fichiers dans mon application) :
Après un langage object est bien entendu pratique pour vérifier qu'un morceau de code implémente telle ou telle interface, mais tu peux toujours te baser sur une description d'interface définie dans un document XML, mais c'est moins "carré" au sens où il est possible que le document XML ne colle pas au module (tu essai alors d'appeler une méthode qui n'existe pas, et bonjour les dégâts)
[^] # Re: voir
Posté par TImaniac (site web personnel) . En réponse au message Modularité. Évalué à 2.
- tu définis ce que ton module doit pouvoir faire et de quoi il a besoin pour le faire
- tu définis une interface pour que les fonctionnalités demandées puissent être accessible depuis ton application
- tu fais du chargement "dynamique" de module au lancement de l'appli pour trouver les modules, vérifier l'interface qu'ils implémentent, et zou tu les utilises.
- quelqu'un qui veut faire un module implémente l'interface correspondante et s'arrange pour que son code/exécutable/librairie soit accessible depuis ton application.
Exemple à l'arrache en français (je veux faire des modules pour supporter plusieurs format de fichiers dans mon application) :
interface FileReader :
propriétés :
string nom_du_module
string[] formats_supportés
méthodes :
ouvrir(string url) retourne fichier
lire_car(fichier fich) retourne car
fermer(fichier fich) retourne bool
Après un langage object est bien entendu pratique pour vérifier qu'un morceau de code implémente telle ou telle interface, mais tu peux toujours te baser sur une description d'interface définie dans un document XML, mais c'est moins "carré" au sens où il est possible que le document XML ne colle pas au module (tu essai alors d'appeler une méthode qui n'existe pas, et bonjour les dégâts)
voilà voilà, amuse toi bieng.