Finding Methods using Reflection

  • Thread starter Thread starter Ian
  • Start date Start date
I

Ian

Hi, I am writing an application and am creating a plug-in interface
for it.

The application will need to 'find' the plug-in's and will then need
to find all accessible methods.

The corresponding methods will need to have a corresponding 'user
friendly' name.

Eg: public void goForward() {...} will need to have a user friendly
name of "Go Forward"

I was thinking of creating an enumeration of custom objects (or maybe
string arrays ) that will store both the method name (for reflection)
and the associated friendly name.

This however seems a bit clunky. Am I on the right track or is there
any better way to do this?
 
Ian,

The idea behind plug-in architecture is that you have one interface, from
which all plugins must derive, and then instantiate. Your calling program
will then know what methods are available, and what to do with them.

This way all a program needs to know is the location of the plugin (easy if
you just enumerate through the .DLL files in a plugin folder say), then call
the methods on the interface, and let the plugin do it's thing.

Does that make sense?

I've got some code you can look at if you like...
http://www.dunesand.com/blog/developer/developer.htm

let me know if you need any more help with that.

Later.
Dan.

Hi, I am writing an application and am creating a plug-in interface
for it.

The application will need to 'find' the plug-in's and will then need
to find all accessible methods.

The corresponding methods will need to have a corresponding 'user
friendly' name.

Eg: public void goForward() {...} will need to have a user friendly
name of "Go Forward"

I was thinking of creating an enumeration of custom objects (or maybe
string arrays ) that will store both the method name (for reflection)
and the associated friendly name.

This however seems a bit clunky. Am I on the right track or is there
any better way to do this?
 
If you have a function in your interface that has a generic sounding name,
e.g. DoWork()
You could create an attribute that can be used to supply a more meaningful
name.
The value of this attribute can be determined at runtime.

[FriendlyDescription("This operation creates a fuzzy warm feeling while you
wait")]
public void DoWork()
{
}


Chris
 
Daniel Bass said:
Ian,

The idea behind plug-in architecture is that you have one interface, from
which all plugins must derive, and then instantiate. Your calling program
will then know what methods are available, and what to do with them.

This way all a program needs to know is the location of the plugin (easy if
you just enumerate through the .DLL files in a plugin folder say), then call
the methods on the interface, and let the plugin do it's thing.

Does that make sense?

I've got some code you can look at if you like...
http://www.dunesand.com/blog/developer/developer.htm

let me know if you need any more help with that.

Later.
Dan.
Click to expand...

Thanks for that Dan, I gave that some thought, but soon dismissed it
as I won't know what functions the 3rd party developer is going to use
- and they need that flexibility.

Looking at your code however has given me a couple of ideas, it may
actually be the path to head down.

Ian.
 
Ian,

Why is that? I ask because this really breaks the whole idea of having an
OOD.
What's your scenario that this would not work in?

Later.
Dan.




Thanks for that Dan, I gave that some thought, but soon dismissed it
as I won't know what functions the 3rd party developer is going to use
- and they need that flexibility.

Looking at your code however has given me a couple of ideas, it may
actually be the path to head down.

Ian.
 
Daniel Bass said:
Ian,

Why is that? I ask because this really breaks the whole idea of having an
OOD.
What's your scenario that this would not work in?

Later.
Dan.
Click to expand...

I am a great fan of using interfaces - I've come from a Java
background where they're used extensively. I also believe they would
work very well in my situation.

The reason I initially dismissed it was I thought it would be more
..netish(?) to not restrict the 3rd party plug-in developer into using
c#. A more appropriate option would be COM (wouldn't it?). Based on my
knowledge (albeit very little in the grand scheme) of .net, an
interface wouldn't work in this scenario. Please feel free to correct
me.

Due to my limited knowlege and my want to get something developed
ASAP, I am now starting to believe it would be better to focus on
using interfaces and restricting the plug-in developer to using c#.
 
Daniel Bass said:
Ian,

Why is that? I ask because this really breaks the whole idea of having an
OOD.
What's your scenario that this would not work in?

Later.
Dan.
Click to expand...

Giving it even more thought (brain about to pop), COM support is prob
a bad idea in total. .net support however is possibly a good idea.
That way, if a user want's to use vb or c++ they can. Would this (from
what I can tell - inexperience is now glowing brightly) affect me
using interfaces?
 
Ian said:
Due to my limited knowlege and my want to get something developed
ASAP, I am now starting to believe it would be better to focus on
using interfaces and restricting the plug-in developer to using c#.
Click to expand...

If your code is CLS compliant, the end user can consume your components in
any .NET language.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)
 
COM is also based on the interfaces concept...
The host needs to know what to call on the plugin, either way.

..Net is great for this sort of thing. If you're not sure the plugins will
only be using .Net, then create a .Net plugin that is a COM proxy, which
will then allow others to use the native COM interface if they wish. I've
recently done this and it all works really well.

If you unsure about all this, make sure you sit down and plan it first. It's
something that requires design and thought before just going at it.

Good luck!

Dan.

Daniel Bass said:
Ian,

Why is that? I ask because this really breaks the whole idea of having an
OOD.
What's your scenario that this would not work in?

Later.
Dan.
Click to expand...

Giving it even more thought (brain about to pop), COM support is prob
a bad idea in total. .net support however is possibly a good idea.
That way, if a user want's to use vb or c++ they can. Would this (from
what I can tell - inexperience is now glowing brightly) affect me
using interfaces?
 
Ian,
I dont think by choosing interfaces you would be restricting people to
C#. VB.net and J# all support interfaces. Also, even COM implementations
of plug-ins use a form of contracts. Essentially the host application
looks through the interfaces in the typelib to determine if certain
methods are implemented. the VS environement uses(d) IConnectedDb (not
to sure of the name, its been a while) for the plug-ins to connect to
the environment.
Also as an additional comment, the plug-in by defenition must
operate in the confines/ contracts of the host application as opposed to
doing its own thing and expecting the host application to manage it
nevertheless.
 
Back
Top