If you can't use interfaces, then given the extra detail: yes I would
*imagine* that the event-based solution would be quicker and more versatile
than reflection - of course, your singleton would then have to be in a
bottom-level assembly (to be referenced by both the primary and external
assemblies), but that's not an issue. If core performance is your primary
concern (real-time system or something) then I would advise simply testing
both in a race, but to me events are a much cleaner solution.
Kind of off-topic (and my own view: form your own opinioin), but
*personally*, I always think of reflection as a last-ditch effort. I'll
happily use reflection at a UI level to simplify displaying / editing
properties (e.g. data-binding on a form, that kind of thing), and I
routinely use a reflection-based popup dialog (even in production code
running as an admin) to review all of the runtime properties of an object
(for debugging / fault identification), but if I find myself using
reflection to invoke methods I always ask: "am I sure I want to do this?".
Sometimes I am, but usually there is a better route.
Marc
"HL" <HL@discussions.microsoft.com> wrote in message
news:F4**********************************@microsof t.com...
Hi Marc,
Thanks for the immediate response.
I need to give more details for clarity. Actually the objects do not
share a common functionality. They need to be called by the caller for
various purposes. Lets say ObjectA's - 'methodA' needs to be called when
the
user performs 'ActionA'. ObjectB's - 'methodB' needs to be called when the
user performs 'ActionB'. Also, there could be more than one object
implementing 'methodB' functionality.
Considering the above, I thought I could have a singleton class (say,
Publisher) that exposes methods and publishes events. The callee objects
can
instantiate the singleton publisher and register for the events that they
are
interested in. The caller can get the Singleton Publisher and call a
method
indicating that 'ActionA' has happened. The Publisher can then fire events
to
all the registered clients.
Will this approach hold good for the above mentioned scenario? Or Is
there a better approach to this problem?
Since the objects do not have a common functionality, I may not be
able
to use the interface approach.
Thanks.
"Marc Gravell" wrote:
With case 2 (objects subscibing to the caller's events), you'd still need
a
way of passing the object reference to the types in order for them to
register with the events.
Personally I don't think reflection is a great idea here: how about a
third
way? Could you make the objects implement a specific interface, and then
fire through that? Maximum speed, plus full type safety etc.
You would presumably need to compile your interface class into a separate
(pref. strongly named) assembly, and reference it from your main program
and
from each of the implementing objects. You'd then essentially have an
interface-based class-factory, so you'd be doing something like:
IMyInterface obj = (IMyInterface)
SomeMethodThatCreatesObjectsFromYourExternalAssemb ly();
obj.SomeMethod();
(assuming that your IMyInterface exposes a void SomeMethod() function)
Marc
"HL" <HL@discussions.microsoft.com> wrote in message
news:42**********************************@microsof t.com... > The requirement is to send some information to other objects. The
> objects
> to
> whom the information has to be sent is not available at compile time.
> The
> names of the types (objects) will be provided through an external file
> in
> which case we can use reflection to create objects of that type at run
> time.
>
> Case 1:
> The methods of those types can be invoked through reflection.
>
> Case 2:
> The caller can publish certain events. The types (objects) can
> subscribe
> for
> the interested events.
>
> Which of the following is faster?
> Calling a method through reflection or Firing events to the objects?
>
>
