By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,458 Members | 1,463 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,458 IT Pros & Developers. It's quick & easy.

Finding Methods using Reflection

P: n/a
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?
Nov 15 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
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.

"Ian" <he******@hotmail.com> wrote in message
news:e7**************************@posting.google.c om...
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?
Nov 15 '05 #2

P: n/a
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" <I'm really @ sick of spam> wrote in message
news:O4**************@TK2MSFTNGP12.phx.gbl...
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.

"Ian" <he******@hotmail.com> wrote in message
news:e7**************************@posting.google.c om...
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?

Nov 15 '05 #3

P: n/a
Ian
"Daniel Bass" <I'm really @ sick of spam> wrote in message news:<O4**************@TK2MSFTNGP12.phx.gbl>...
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.


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.
Nov 15 '05 #4

P: n/a
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.

"Ian" <he******@hotmail.com> wrote in message
news:e7**************************@posting.google.c om...

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.
Nov 15 '05 #5

P: n/a
Ian
"Daniel Bass" <I'm really @ sick of spam> wrote in message news:<#f**************@TK2MSFTNGP11.phx.gbl>...
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.


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#.
Nov 15 '05 #6

P: n/a
Ian
"Daniel Bass" <I'm really @ sick of spam> wrote in message news:<#f**************@TK2MSFTNGP11.phx.gbl>...
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.


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?
Nov 15 '05 #7

P: n/a
Ian wrote:
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#.


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)
Nov 15 '05 #8

P: n/a
This may also be helpful:

http://www.geocities.com/jeff_louie/OOP/oop13.htm

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 15 '05 #9

P: n/a
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.

"Ian" <he******@hotmail.com> wrote in message
news:e7**************************@posting.google.c om...
"Daniel Bass" <I'm really @ sick of spam> wrote in message
news:<#f**************@TK2MSFTNGP11.phx.gbl>...
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.


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?
Nov 15 '05 #10

P: n/a
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.

Ian wrote:
"Daniel Bass" <I'm really @ sick of spam> wrote in message news:<#f**************@TK2MSFTNGP11.phx.gbl>...
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.

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#.


--
Regards,
Dilip Krishnan
MCAD, MCSD.net
dilipdotnet at apdiya dot com
Nov 15 '05 #11

P: n/a
Ian
Thanks everyone for your help. I've received some serious pointers here. :)
Nov 15 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.