Quelles sont les différentes manières de mettre en place un système de plugin?

Question

Je ne recherche pas tellement les réponses spécifiques à une langue, mais juste des modèles généraux pour la mise en œuvre d'un système de plug-in (si vous voulez savoir, j'utilise Python). J'ai ma propre idée (enregistrer des rappels, et c'est à peu près tout), mais je sais que d'autres existent. Qu'est-ce qui est normalement utilisé et qu'est-ce qui est raisonnable?

  

Qu'entendez-vous par système de plug-in? Les contenants de dépendance et d’injection de dépendance semblent-ils une bonne solution?

Je veux dire, euh, eh bien, un moyen d’insérer des fonctionnalités dans le programme de base sans le modifier. Je n'avais pas l'intention de le définir quand je partirais. L’injection de dépendance ne pas l’apparence qui convient à ce que je fais, mais je ne connais pas grand chose à leur sujet.

Answer 1

Il existe un très bon épisode de la radio d'ingénierie logicielle qui pourraient vous intéresser.

Pour référence future, j’ai reproduit ici le "rel =" nofollow noreferrer "> Règles pour les facilitateurs " ( lien alternatif ) donné dans l'excellent Contribution à Eclipse par Erich Gamma, Kent Beck.

  

  
• Règle d'invitation - Dans la mesure du possible, laissez les autres contribuer à vos contributions.
  
• Règle de chargement paresseux: les contributions ne sont chargées que lorsqu'elles sont nécessaires.
  
• Règle de plate-forme sécurisée - En tant que fournisseur d'un point d'extension, vous devez vous protéger contre les erreurs de comportement des extensions.
  
• Règle du fair-play - Tous les clients respectent les mêmes règles, même moi.
  
• Règle d'extension explicite - Indiquez explicitement où une plate-forme peut être étendue.
  
• Règle de diversité - Les points d’extension acceptent plusieurs extensions.
  
• Bonne règle de protection - Lorsque vous passez le contrôle en dehors de votre code, protégez-vous.
  
• Règle d'API explicite: séparez l'API des éléments internes.
  
• Règle de stabilité - Une fois que vous avez invité quelqu'un à contribuer, ne modifiez pas les règles.
  
• Règle d’API défensive: ne révélez que l’API dans laquelle vous avez confiance, mais préparez-vous à en révéler plus lorsque les clients le demandent.
  

Answer 2

Une architecture de plug-in simple peut définir une interface de plug-in avec toutes les méthodes que le plug-in doit implémenter. Le plugin gère les événements de l'application et peut utiliser le code standard de l'application, les objets de modèle, etc. pour mener à bien ses tâches. En gros, la même chose qu’un formulaire ASP.NET, sauf que vous substituez plutôt que vous implémentez.

Personne ne m'a appris cette partie, et je ne suis pas un expert, mais je me sens: en général, un plugin sera moins stable que son application, de sorte que l'application doit toujours être sous contrôle et ne lui donner que des opportunités périodiques d'agir. Si un plugin peut enregistrer un observateur, les appels du délégué doivent être essayés / interceptés.

Answer 3

En Python, vous pouvez utiliser le système de points d'entrée fourni par setuptools et pkg_resources . Chaque point d’entrée doit être une fonction qui renvoie des informations sur le plug-in: nom, auteur, fonctions de configuration, de démontage, etc.

Answer 4

Qu'en est-il de la fabrique abstraite ? Votre programme de base définit la manière dont les concepts abstraits interagissent les uns avec les autres, mais l'appelant doit fournir l'implémentation.