Aide sur une structure de "plug-in"
Obi
Membre
J'aimerais avoir votre avis éclairé sur un problème de structure.
Je bosse sur un projet dont le code est simple et qui n'est pas censé évoluer sensiblement. J'aimerais donc faire un système de plug-ins très simple pour étoffer les fonctionnalités.
J'ai cherché de la doc qu'il faut que je décortique mais j'aimerais savoir si vous penser que c'est une voie qui mérite que j'y passe du temps.
Alors, actuellement, j'ai une classe "Action" qui a les méthodes de bases pour traiter les données que je lui envoie. J'envoie un objet (qui contient les données) à une instance de "Action", elle les traite et me renvoie l'objet modifié. Elle connaà®t rien d'autre, c'est vraiment basique.
Mon idée est de faire des sous-classes de "Action" qui "surchargent" la seule méthode qui est appelée et qui retourne les données qu'elle aura traité à sa façon.
J'aimerais faire des "plug-ins" que je chargerais au lancement de mon appli, dont je proposerais une liste à l'utilisateur et dont j'appellerais l'unique méthode.
J'y vois 2 avantages :
- ça me permettrait de ne plus toucher au coeur de l'appli et de créer / mettre à jour les fonctionnalités plus facilement (souplesse pour moi et pour l'utilisateur final)
- ça permettrait d'enrichir le soft avec des plug-ins d'autres développeurs
Pensez-vous que ça soit une option viable ? Est-ce long à implementer ? Avez-vous des explications-exemples-urls que je pourrais utiliser pour valider ce choix ?
Merci !Â
Je bosse sur un projet dont le code est simple et qui n'est pas censé évoluer sensiblement. J'aimerais donc faire un système de plug-ins très simple pour étoffer les fonctionnalités.
J'ai cherché de la doc qu'il faut que je décortique mais j'aimerais savoir si vous penser que c'est une voie qui mérite que j'y passe du temps.
Alors, actuellement, j'ai une classe "Action" qui a les méthodes de bases pour traiter les données que je lui envoie. J'envoie un objet (qui contient les données) à une instance de "Action", elle les traite et me renvoie l'objet modifié. Elle connaà®t rien d'autre, c'est vraiment basique.
Mon idée est de faire des sous-classes de "Action" qui "surchargent" la seule méthode qui est appelée et qui retourne les données qu'elle aura traité à sa façon.
J'aimerais faire des "plug-ins" que je chargerais au lancement de mon appli, dont je proposerais une liste à l'utilisateur et dont j'appellerais l'unique méthode.
J'y vois 2 avantages :
- ça me permettrait de ne plus toucher au coeur de l'appli et de créer / mettre à jour les fonctionnalités plus facilement (souplesse pour moi et pour l'utilisateur final)
- ça permettrait d'enrichir le soft avec des plug-ins d'autres développeurs
Pensez-vous que ça soit une option viable ? Est-ce long à implementer ? Avez-vous des explications-exemples-urls que je pourrais utiliser pour valider ce choix ?
Merci !Â
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Tous les élements qui doivent être sortis de l'appli (et donc situés autre part sur le disk) doivent être mis dans un bundle.
Depuis ton appli, il suffit de charger le bundle pour y récupérer ces éléments.
Les éléments peuvent être de tout type, et surtout, cela peut être du code (en fait des classes qui tu as écrit). Au moment du chargement du bundle, tu pourras charger ces classes, les instancier (alloc/init) puis appeller les méthodes qu'elles implémentent.
.
Ca marche même avec une sous-classe d'une classe qui n'est pas dans le plug-in mais dans l'appli ?
En tout cas, si c'est simple à faire, je commence dès maintenant ! :adios!:
Bien sûr !
Ca s'appelle le dynamisme, et Objective-C est profondément dynamique.
Il faut juste que la classe mère soit déjà chargée au moment du chargement du plugin implémentant sa "fille".
.
Je vais donc me lancer dans cette structure sans hésiter. J'ai récupérer un tutoriel sur Cocoa dev central qui m'a l'air très complet et bien expliqué. Visiblement dans cet exemple, l'appli et le plug-in communiquent via un protocole et pas par système de sous-classe. Ma structure étant plutôt light, je ne pense pas avoir trop de mal à la modifier pour coller à l'exemple.
Si j'arrive à quelque chose de potable, je vous montrerais le projet. Ca vous donnera peut-être des idées de plug-ins  :P
J'arrive, depuis l'appli, à charger les plug-ins, instancier leur classe principale et appeller leurs methodes. Le tout via un protocole dont je partage le fichier ".h" entre les projets.
J'ai même fait un cluster pour avoir tous mes plug-ins de base dans 1 seul bundle.
Maintenant, je voudrait créer une classe "Utilitaires" dans l'appli que les plug-ins pourraient appeler.
Dans le projet de l'appli, j'ai les fichiers "Utilitaires.h" et "Utilitaires.m", ça compile sans problème.
Dans le projet du plug-in, j'inclus le fichier "Utilitaires.h" mais ça refuse de compiler quand j'appelle cette classe.
En gros j'aimerais que le plug-in puisse accéder à certaines des classes créées dans l'appli mais sans donner le .m et le code des méthodes, juste les headers.
Vous avez une piste ? Merci d'avance !Â
Mais dans ce cas, ce n'est plus vraiment une architecture plug-in que tu réalises (puisque les dépendances vont dans les 2 sens).
Pour résoudre de manière simple et rapide ton problème, c'est d'utiliser ta classes Utilitaires dans les plug-in sans la typer : tu utilises id pour faire les déclarations, et dans ce cas, le compilateur ne fera pas de vérification de typage (donc pas besoin de .h, et encore moins de .m).
Une fois de plus, ça démontre la puissance de l'Objective-C qui n'a besoin de connaitre le type d'un objet pour compiler.
.
Cool, ca marche nickel ! J'avais envisagé cette solution mais je pensais que c'etait un peu sale
Je crée une instance de Utilitaires dans l'appli que j'envoie aux plug-ins au moment de leur init.
Ca me mets des warnings à la compilation à cause du id mais le principal, c'est que ca marche !
Merci encore BruÂ