On Tue, 26 Jun 2007 12:48:00 -0700, JJ <JJ@discussions.microsoft.com>
wrote:
I have a logger component that logs to multiple sources, ie textfile,
eventlog etc.
and I have two methods that depending on where I call up my logger comp.
one
of them will be called. For ex. if I throw an exception I want to call
one
method and if I dont, I am just logging some info to eventlog, I will
call
the other. Now i'm wondering would it make sense to use delegates, one
for
each method to call methods in my window service? How would I go about
coding
it? Or should I not even bother and just instantiate the logger class and
call the methods when needed?
From your description, I don't see anything that clearly indicates a need
for delegates. It depends on how you would use the delegate. If you are
envisioning a design in which one of two delegates is chosen from
depending on the situation (exception or event logging), then it seems to
me that you might as well just call the method you need to be called. On
the other hand, if you are envisioning a design in which you have a single
delegate, initialized to one of two values depending on the situation,
then perhaps a delegate does make sense.
It just depends, and I don't see enough information in your post to be
able to determine what you intend.
More generally...
If you can accomplish the same exact behavior without using delegates,
then why would you use delegates?
Conversely, if you cannot accomplish the same exact behavior without using
delegates, then why would you attempt to do so?
To me, these are interesting questions to ask yourself when you are
thinking about the design.
It seems to me that delegates are useful in a particular type of
situation: you want to be able to specify at run-time a method to call,
but don't have a situation that lends itself to creating an abstract class
that clients can use to provide derived versions of at run-time. If the
code doing the calling will always call the same method, and that method
can be included at compile time, then there's no need for either.
As an example of using an abstract class, many of the logging type
features in .NET use something that derives from TextReader, usually
taking a StringReader or StreamReader instance as appropriate. No need
for delegates there: each derived class has specific functionality that is
mapped to the general-purpose methods specified in TextReader. By
implementing the derived class (or in this case, using a built-in
implemented derived class) and providing that as the base class, any code
that needs to call different methods depending on context can do so
without know specifically what code it needs to call.
Events are .NET's classic example of the use of delegates (though by no
means the only example). At run-time you have a situation in which one
class wants to be callable by another class, but it doesn't make sense to
derive that one class from some specific abstract class.
You could accomplish similar effects by using an interface, but if you've
got a class that will have dozens of different event handlers, all of
which are subscribed to different kinds of events, the list of interfaces
would get out of hand, and it would be sort of silly to have dozens of
interfaces, all of which have just one method in them. Here, a delegate
works nicely, as the method itself can be implemented in any class you
like, without worrying about inheritance structures, and any class can
implement as many delegates as needed without creating a lengthy,
confusing inheritance list (acknowledging of course that in C#, there's
really only one class that's inherited at most...interfaces are only sort
of like inheriting a purely abstract class).
So, that's the general description. You can either look at that and try
to apply it to your own situation, or you can clarify what your own
situation actually is, so that others can provide better insight as to
whether a delegate seems appropriate or not.
Pete
