Plugins: Abstract class factory vs. Interfaces.

  • Thread starter Thread starter Michael McCarthy
  • Start date Start date
M

Michael McCarthy

I want to develop plugin support for a system.montitor module I am
working on. A lot of the modules will do mostly interop stuff for an
older system, but I want to use it myself as well to monitor event logs
and other things as I think of them...

I've seen two ways of doing this, the abstract class factory, or the
interface... the module logic is fairly simple, watch something -> get
the result -> notify / fix / and or log it...

I've seen a few articles, anyone have any advice on the best place to start?
 
Thanks for the link (and the rest of the material looks to be a good
read as well)... C# is my first OO language, but it's not been that
dificult to pick up.

regards,
M.
 
Jeff said:
http://www.geocities.com/jeff_louie/OOP/oop13.htm
Click to expand...

Gaack. You should iterate plugin types with
"assembly.getExportedTypes()", not "assembly.GetTypes()". The result
array is smaller, when you have TypeInformation permission. (And
GetTypes may show you private types that you can't create, anyway.)

And you should test the types with

typeof(MyInterface.IDrawable).IsAssignableFrom(t)

not

t.GetInterface("MyInterface.IDrawable")

IsAssignableFrom is faster than the string lookup, and not subject to
shadowing. (Imagine that the plugin defines its own MyInterface
namespace, which contains its own IDrawable interface, and that an
exported types supports this private interface.)

Curiously, you do use IsAssignableFrom in
<http://www.geocities.com/jeff_louie/OOP/oop18.htm>.
 
Heh Heh. I got SMARTER between Chapter 13 and 18 :). Actually both
method
calls are there in Chapter 13, I just commented out the wrong one. I
will look
into getExportedTypes. Thanks for the feedback.

Regards,
Jeff
 
I do a lot of custom plugin development for my various applications, web
sites, and controls... plugins at every level.

With abstract classes, all you have to do is inherit the object, which can
provide a fully functional, minimally implemented plugin to boot. Taking
the interface approach will require you to fully implement the plugin
yourself everytime.

Personally, I prefer to require Interfaces for my plugins but provide an
abstract base class that fully implements the required Interfaces for me if
I choose to create a concrete implementation. The reason for this is
because, in my situations, my plugin might already derive from
MarshalByRefObject or Component. In such cases, they can't act as plugins
if I must inherit a PluginBase to be a plugin. For the most part, depending
on your architecture and restrictions, this can be perfectly feasible and
desirable. In my case, it is unnacceptable. So, in such cases, I must
instead be forced to implement the required interfaces myself, but things
work exceptionally well and I wouldn't have it any other way.

Over the years, I've created a very robust plugin framework that I reference
in all my host applications/utilities but nothing is automatic, each Host
must expose what a plugin can/cannot do. Sometimes my plugins can even
customized with their own set of plugins.

In scenarious requiring greater flexibility or complexity of various
degrees, requiring Interfaces would be a better way to go (depending on what
you want to allow/not allow) and then just provide a base to derive from and
still allow the users to implement the required interfaces if they choose.
I think, for your situation, there's no pressing need to require Interfaces;
abstract classes are fine (just derive from it and override the appropriate
properties/methods to provide a concrete class and you're ready to go).

Attributes? Personally, I don't use attributes in my plugins anymore
because of various hassles and performance issues with Reflection. Anyway,
that isn't a cold, hard rule. Using Attributes could very well be a viable
tool in your architecture if you choose to support them, I'm only mentioning
that I've abanded them for various reasons, in favor of better performing,
simpler approaches.

Nothing in here is a hard rule and ultimately, the solution must fit the
architecture and what you want out of it. The simplest approach, since your
service sounds pretty simple, would be just to use an abstract class and
derive your plugins from that.

Hope this helps.

Thanks,
Shawn



Michael McCarthy said:
I want to develop plugin support for a system.montitor module I am
working on. A lot of the modules will do mostly interop stuff for an
older system, but I want to use it myself as well to monitor event logs
and other things as I think of them...

I've seen two ways of doing this, the abstract class factory, or the
interface... the module logic is fairly simple, watch something -> get
the result -> notify / fix / and or log it...

I've seen a few articles, anyone have any advice on the best place to
Click to expand...
start?
 
Back
Top