6

Problem:
I am constructing a framework which accepts a file, translates it and executes it. The framework should be able to handle any type of file, to this end i have provided a method of uploading a DLL containing classes and methods for translating and executing a file. What i am looking for, is the best way to define the plugin interface

Solution A:
Define a set of interfaces which are publicly available. Plugins should implement these interfaces.

Solution B:
Define some abstract classes which are publicly available. Plugins should inherrit and override the abstract methods on these classes.

Solution C: rcravens
Pass interfaces around inside the code, create an abstract class which is publicly available to allow for plugin extensibility. Chosen
This solution was chosen ahead of interface only because it enables basic implementation (handy in this case). It was chosen ahead of abstract class only because it enables mocking within the code. The composition frameworks are excellent, but a bit over the top for something as lightweight as this application where only limited extensibility is desired.

Solution D: Jay and Chris Shain
Implement a composition framework (such as Managed Extensibility Framework(MEF)) and build around it

If any new solutions appear, i will add them to this list. The answer will go to the person who is best able to justify their solution (possibly with advantages and limitation)

Thanks in advance,
Tech Test Dude

Community
  • 1
  • 1
David Colwell
  • 2,450
  • 20
  • 31
  • Whats about MEF and MAF? I dont't know what you mean when you talk about translation, but MEF and MAF (possibly enriched with some usual DI stuff) are made for building composite applications. You might want skim read the Prism (Composite WPF) code, the whole stuff is about composite applications aka modules/plugins. If you are talking about web applications the source of Orchard CMS could be interesting too. These guys have build a nice plugin infrastructure on top of ASP.NET MVC. – Jay Aug 16 '11 at 01:00
  • The application in question is a webservice, sitting on a server. The idea is that many people can provide files for 'translation' and some people can provide plugins. When people provide their files, they will select which plugin should be used to 'translate' them. The actual UI end (WPF, MVC, etc etc) is not the issue right now. I have thus far stayed away from pre-defiend frameworks because they tend towards being fairly unweildy. Correct me if i am in error – David Colwell Aug 16 '11 at 01:08
  • Haven't worked with MAF yet and don't know if it still maintained by MS but I think at least MEF should provide the necessary infrastructure. It's not limited to GUI stuff. Though I think @Chris Shain is right, don't reinvent the wheel. BTW: Whats about security? I mean someone could upload malicious code as a plugin. Seems that a sandbox is required. – Jay Aug 16 '11 at 01:18
  • Agreed on the sandbox. Post it as an answer so i can upvote it. – David Colwell Aug 16 '11 at 01:21
  • +1 for follow through and justification of the chosen answer – Chris Shain Aug 16 '11 at 01:38

3 Answers3

4

What you are writing sounds suspiciously like what Managed Extensibility Framework supports: http://mef.codeplex.com/. Maybe just use that and avoid re-inventing the wheel?

Chris Shain
  • 50,833
  • 6
  • 93
  • 125
  • A few lines of code may be used to implement a plugin engine, see http://www.c-sharpcorner.com/UploadFile/rmcochran/plug_in_architecture09092007111353AM/plug_in_architecture.aspx, a heavy framework is not always mandatory – Aerospace Jan 20 '14 at 12:00
3

At the lowest level I believe you need interfaces. This allows most mocking frameworks to easily provide fakes. Around your code you should pass around the interfaces. If you need some base implementation that can be refactored into an abstract base class, then do it. Abstract base classes and interfaces are not mutually exclusive concepts. Some times it makes sense to have both.

rcravens
  • 8,320
  • 2
  • 33
  • 26
  • So as an example, i would have `ITranslator` which would then declare all valid methods for translating, and an abstract class TranslatorBase which declares some basic implementation. The problem then arises when i start using reflection to look for the implementations within the DLL. Do i just search for `ITranslator` implementations? Or do i in fact require them to inherit `TranslatorBase`? Which of these is public, and which is just for the internals to use? thanks for your reply – David Colwell Aug 16 '11 at 00:48
  • Please tell me if the edit i made to the question sufficiently encapsulates your answer – David Colwell Aug 16 '11 at 00:53
3

I don't think there's a better solution between interface or abstract class, it really depends on what you need. But personnally I would probably go with abstract class, for the simple fact that it offers more flexibility.

You could provide some abstract methods that are essential to define particular behavior of the plugin, while virtual methods offers a way to optionnaly override a default behavior.

The abstract class also can provide some utility methods that could be usefull to the plugin's authors.

Basically, an abstract class can offer all that an interface offer, and more. So it's probably a better for future extension.

Johnny5
  • 6,664
  • 3
  • 45
  • 78