Plugin-based application, general designing questions

[S. Lorétan]

Hi guys.

I am preparing the rewriting of an huge existing application in VB6. This
software is a mess of 10 years of patchs and new functionalities added
randomly, and didn't have any logical or oriented-object background.

This software is used by many differents persons, and there is a LOT of
functionalities that exists only for one or two of them. So, I want to use a
plugin-based system. That's it for the background.

Now, the questions.

1. I've read a lot of articles about plugin-based softwares, and I found
that they use an interface and then design the plugins based on it. Why an
interface, and not an abstract class, who can implement some 'global'
functions (database access, authentications, etc)? Is there a problem with
an abstract class based plugin type?

2. Because of the interface implementation, there is no way to have global
methods, designed on the host-app, and called by the plugins. Well, there
might be some way, but I'm still a newbie, and I don't know how. Can you
help me with that?

3. I've read some stuff about "signed DLL". Is this possible to load only
*signed* plugins, to be sure that the user won't use some other stuff than
ours? (ah, ah) How?

4. Is there maybe some doc' on software designing with plugins? I've found
only things about the technical way to do it, not about the "philosophical"
idea behind.

Thank you very much.

PS: Sorry, my english is poor.

 

[Wiebe Tijsma]

Hi,

Interface or abstract class depends on your requirements. In this case
I'd probably use an interface to let plug-in developers choose their own
base class.

If you're using the Enterprise libary, I'd have a look at the 'plug-in
loader application block':
http://msdn.microsoft.com/msdnmag/issues/06/07/PatternsAndPractices/default.aspx

otherwise see these articles on the codeproject:
http://www.google.com/search?hl=en&...site:www.codeproject.com+plug-in+architecture

Good luck,

Wiebe Tijsma

 

[ThunderMusic]

See the answers below :

1. I've read a lot of articles about plugin-based softwares, and I found
that they use an interface and then design the plugins based on it. Why an
interface, and not an abstract class, who can implement some 'global'
functions (database access, authentications, etc)? Is there a problem with
an abstract class based plugin type?

Because you can implement many interfaces at once but cannot inherit more
than one class at once. You can do it with an abstract base class, but one
day or another you'll find yourself in the same situation you were with your
VB6 application and you'll face a requirement you cannot meet without
patching because you didn't tought about it in the beginning..

2. Because of the interface implementation, there is no way to have global
methods, designed on the host-app, and called by the plugins. Well, there
might be some way, but I'm still a newbie, and I don't know how. Can you
help me with that?

Absolutely... What I've done to workaround this is create an interface each
plugins must implement and a base class that provide the plugins I develop
with general global methods, so now my plugins inherit my base class to have
access to all those global methods (made them protected) and if a problem
arise, I can always go back to my implementing my interface and build
another base class from there. You get the point?

3. I've read some stuff about "signed DLL". Is this possible to load only
*signed* plugins, to be sure that the user won't use some other stuff than
ours? (ah, ah) How?

can't help you on this one... sorry...

4. Is there maybe some doc' on software designing with plugins? I've found
only things about the technical way to do it, not about the
"philosophical" idea behind.

What do you mean by philosophical? Why to use plugins? How to think
plugin-oriented?


I hope it helps

ThunderMusic

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

1. I've read a lot of articles about plugin-based softwares, and I found
that they use an interface and then design the plugins based on it. Why an
interface, and not an abstract class, who can implement some 'global'
functions (database access, authentications, etc)? Is there a problem with
an abstract class based plugin type?

Not at all, if you have some shared features you should use an abstract
class instead.
Regarding 'global' your example is not correct, in these cases is better to
use a static class. IF you also need flexibility then use a singleton
factory ( a class that has only one instance and you can select which
instance from several options, but once you select one and create it it
exist for ever and no instance of the others classes can be created)

2. Because of the interface implementation, there is no way to have global
methods, designed on the host-app, and called by the plugins. Well, there
might be some way, but I'm still a newbie, and I don't know how. Can you
help me with that?

There is no way to ahve global methods in .net no matter what. you could
have a singleton as I described it above.

3. I've read some stuff about "signed DLL". Is this possible to load only
*signed* plugins, to be sure that the user won't use some other stuff than
ours? (ah, ah) How?

Take a look in strong naming your dlls .

4. Is there maybe some doc' on software designing with plugins? I've found
only things about the technical way to do it, not about the
"philosophical" idea behind.

take a look at http://www.pobox.com/~skeet/csharp/plugin.html

 

[S. Lorétan]

Hi,

Thank for your advices. It's true that I'll probably want to inherit from
another class sometime. Now, I understand why using Interface instead of
abstract class.

 

[S. Lorétan]

Hi,

See the answers below :

Thank you for your help.

Because you can implement many interfaces at once but cannot inherit more
than one class at once. You can do it with an abstract base class, but one
day or another you'll find yourself in the same situation you were with
your VB6 application and you'll face a requirement you cannot meet without
patching because you didn't tought about it in the beginning..

True. Thank you.

Absolutely... What I've done to workaround this is create an interface
each plugins must implement and a base class that provide the plugins I
develop with general global methods, so now my plugins inherit my base
class to have access to all those global methods (made them protected) and
if a problem arise, I can always go back to my implementing my interface
and build another base class from there. You get the point?

I understand it too. Thanks.

can't help you on this one... sorry...

No problem, I'll be digging some more.

What do you mean by philosophical? Why to use plugins? How to think
plugin-oriented?

Your 2nd option.

I hope it helps

It helps surely. Thank you very much.

 

[Dave Sexton]

Hi,

3. I've read some stuff about "signed DLL". Is this possible to load only *signed* plugins, to be sure that the user won't use
some other stuff than ours? (ah, ah) How?

In addition to Ignacio's remark about strong-naming your assemblies, take a look at the following to enforce that of your plug-ins
from your main assembly:

StrongNameIdentityPermission Class on MSDN:
http://msdn2.microsoft.com/en-us/li...permissions.strongnameidentitypermission.aspx