Comment procéder pour créer un logiciel enfichable?

20

Si vous avez une application quelconque et que vous souhaitez que vos utilisateurs puissent y écrire des plugins, comment l'application devrait-elle être conçue?

Que devez-vous prendre en compte, quels sont les modèles de conception pour cela, etc.?

design plugins extensibility

— user9238
source

Des modèles comme Observateur, Médiateur, Chaîne de responsabilité de la commande et de la responsabilité viennent à l'esprit

— Mchl

3

@Mchl: veuillez publier votre réponse en tant que réponse, pas en tant que commentaire.

— S.Lott

Vous devriez jeter un oeil à Mef et les informations MSDN

— Luc Bos

Je pense que ce n'est pas assez détaillé pour ça

— Mchl

@Mchl: "pas assez détaillé"? Alors pourquoi faire un commentaire? C'est clairement une réponse. Veuillez poster les réponses comme réponses.

— S.Lott

13

Cela dépend un peu de votre plate-forme, mais certaines choses générales à garder à l'esprit

Versioning Que se passe-t-il si vous mettez à jour votre application, tous les anciens plugins deviennent-ils obsolètes (le problème de Firefox)

Isolation Les plugins peuvent-ils faire ce qu'ils veulent? Tu leur fais toujours confiance? Ou devez-vous les exécuter dans une sorte de bac à sable et demander des autorisations.

Mises à jour Comment gérez-vous les mises à jour des plugins?

Sécurité Comment garantissez-vous l'auteur d'un plugin, empêchez-vous l'usurpation d'identité ou que l'utilisateur soit incité à installer du code malveillant? Habituellement résolu par une sorte de signature de code

Sérialisation Souvent, lorsque vous utilisez une isolation quelconque, vous devez sérialiser des informations entre différents threads ou processus. Comment procédez-vous le plus efficacement?

Extensibilité Quels aspects devez-vous étendre? Comment maximiser le potentiel des plugins sans que l'API devienne trop lourde.

Si vous ciblez des développeurs tiers pour des plugins, je dirais que la chose la plus importante (d'après mon expérience) est de voir l'api et les classes de plugins comme complètement différents du reste de l'application, et de les rendre aussi faciles à développer pour que possible. Il est très facile pour l'architecture de l'application principale de «se fondre» dans les plugins afin que les auteurs de plugins doivent en apprendre beaucoup plus qu'ils ne le doivent. Rendez-leur la tâche facile, réfléchissez au type d'interface et d'expérience que vous souhaitez en tant qu'auteur de plugin.

Un autre bon état d'esprit est de ne pas penser comme "Le plugin fera toutes ces choses (dans le code) mais plutôt," le plugin doit fournir ces informations ". De cette façon, l'application peut consommer les informations nécessaires et faire le traitement réel qui simplifiera le plugin.

De manière générale, chaque fois que vous pouvez adopter une approche descriptive (métadonnées, comme xml) plutôt que du code, vous avez un gros avantage car les métadonnées sont plus faciles à transporter, à versionner, à déployer, à sécuriser et peuvent plus facilement être configurées par des tiers

— Homde
source

1

+1 Cela ne répond pas directement à la question, mais ce sont des questions importantes à garder à l'esprit

— Adriano Carneiro

Je crois que ces questions sont traitées avant que quiconque ne commence à développer le mécanisme d'extensibilité réel

— Gus

9

J'ai écrit cet article Code Project sur l'utilisation de MEF pour l'extensibilité dans .NET. C'est une bonne introduction.

Il existe d'autres cadres d'extensibilité pour .NET, tels que l'architecture de complément de SharpDevelop , Mono.Addins et System.AddIn .

Pour Java, il existe l' architecture de plug-in Eclipse .

Le schéma général est le suivant:

Vous définissez un contrat (normalement une interface) entre l'hôte et l'extension
Vous avez besoin d'un mécanisme de découverte qui s'éteint et recherche les extensions installées
Vous devez être en mesure de charger dynamiquement les extensions et d'en informer l'hôte

En pratique, il partage beaucoup avec l'injection de dépendance et le modèle de stratégie.

— Scott Whitlock
source

+1 MEF et System.AddIn sont deux bonnes choses à regarder. Même si vous ne les utilisez pas, ils présentent tous les deux de bons concepts.

— RationalGeek

@jkohlhepp - Je suis d'accord, et je suggérerais également une plongée en profondeur dans l'architecture SharpDevelop parce qu'il y a beaucoup écrit à ce sujet, c'est open source (tout comme MEF, btw), et il est bien conçu.

— Scott Whitlock

3

Il vous suffit de fournir une interface pour les plugins.

Il devrait contenir au moins une Activate-Methode (un point d'entrée), mais vous voudrez aussi des choses comme Initialize etc.

Et il devrait y avoir la possibilité de communiquer avec l'application hôte d'une manière similaire au registre, par exemple pour enregistrer des éléments de menu. Il faut donc fournir des registres pour les éléments modifiables / extensibles pour les plugins.

De plus, il devrait y avoir un stockage accessible pour les données et les objets de l'application hôte, afin que les plugins puissent appeler ses routines. Cela peut facilement être fait en utilisant un conteneur DI comme Unity et en laissant les plugins y accéder, afin qu'ils puissent résoudre les services dont ils ont besoin.

Un Event-Aggregator est probablement une bonne idée également, donc les plugins peuvent lancer des événements et réagir aux événements d'autres plugins et de l'application hôte de manière découplée. Vous en voulez vraiment un!

— Faucon
source