Plugin Driven Design Technique needed? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 4 years ago.

开发者_如何学编程 Improve this question

A project that a group of mine is starting is going to be focused around the use of plug-ins which are extremely specific to the user. We are trying to essentially create an application that without the plug-ins is nothing more then a running environment, and hence will be driven by the addition of the user-specific plugins.

I am not too experienced in this area of designing the application around plug-ins. How should I go about this process of creating a basic, essentially abstract application, and then creating these "dynamic" user-specific plugins to be used by the application?

---

As 'hobbs' pointed out, knowing the language would be beneficial to getting a better answer!

But regardless, I'll give you details on the Command Design Pattern which is frequently used in Java or any other object oriented languages.

See Command Design Pattern - Wikipedia and Command Design Pattern - Java Tip 68 (for implementation details)

I use this pattern frequently when I know I will want to run 'plugins' in a generic manner (sometimes when I don't have all the details at that point in time). With more specs and/or security constrains you would want to alter this pattern respective of such constraints and include sandbox limitations, etc. That is all up to you!

Your client would begin by writing plugins using the interface you provide them (see links above). With a compiled class, your clients would then be able to drop their plugins into a folder for example.

When your application is ready to run the plugins, you would load a list of plugin candidates (either an xml file or scan the class files within a specific directory) and load each class in order to execute them one by one.

You can decide if you want to run these plugins in a specific sequence or in parallel (threaded design).

Note that if your plugins must access a specific state or API, you can provide it as a parameter to your plugin.

All of this works beautifully and I'm sure it can easily be adapted to fit almost any language.

Good luck,

Jeach!