Re: Delegates VS interfaces - some confusion
- From: "Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx>
- Date: Wed, 14 Jan 2009 16:25:24 -0800
On Wed, 14 Jan 2009 14:19:43 -0800, <beginwithl@xxxxxxxxx> wrote:
Sorry for so many questions ( again )
Questions are great. Don't be sorry. :)
What follows are excerpts from msdn article regarding the differences
between interfaces and delegates and when you should choose one over
the other. Anyways, I don’t quite understand the arguments they
present:
msdn:
“Use a delegate in the following circumstances:
• It is desirable to encapsulate a static method.
• A class may need more than one implementation of the method."
a) “It is desirable to encapsulate a static method.”
I assume they are referring to the fact that interfaces can’t declare
static methods and thus if you want to call a static method, you
should choose a delegate?
Yes. You can't implement an interface with a static class. You could implement an interface and then call a static method from the implementation, but then you're not really encapsulating the static method itself, IMHO.
“A class may need more than one implementation of the method.”
b) What class are they referring to? An observer class or publisher
class?
I can't speak for the author, but I'd guess they mean any class that _implements_ the method. That is, if you have a situation where the class is _always_ going to use some specific, single implementation for the method, then designing around that with an interface makes more sense. On the other hand, if the class has multiple implementations to choose from, using each at different times according to different input, then a delegate would be more appropriate.
c) By ”By more than one implementation of the method” are they
talking about method overloading? But, interface methods can also be
overloaded!
No, that's not what they are talking about. They are talking about having multiple methods with the same exact signature (but not the same name), each of which implements some specific functionality in a different way.
For example, when sorting a collection, you may sometimes want to sort in ascending order and sometimes in descending order. One easy way to do this is to provide two comparer methods, one that returns the "normal" comparison (i.e. returns -1 with the compared-to field/object is "greater") and another that returns the "reversed" comparison (i.e. returns -1 when the compared-to field/object is "less").
d) In any case, I don’t understand how needing more than one method
implementation qualifies a delegate as being more appropriate?
Because when implementing an interface, only one method can implement one member of the interface, whereas with a delegate you can specify the implementation at run-time arbitrarily.
Of course, you could implement an interface and then use call delegate for the actual implementation, but as I mentioned in my other reply, this seems like a poor approach.
2)
Continuing with msdn article:
“Use an interface in the following circumstances:
• A class only needs one implementation of the method.
• The class using the interface will want to cast that interface to
other interface or class types.
• The method being implemented is linked to the type or identity of
the class: for example, comparison methods. “
a) “A class only needs one implementation of the method.”
This question is sort of continuation of the previous one: So why is
interface more appropriate if class only needs to implement one
method?
See above.
b) “The class using the interface will want to cast that interface to
other interface or class types.”
In what situations would you need to cast that interface to other
interface ( or class ) and thus would choose interface over delegate
for that reason alone?
My personal preference would be to not cast interfaces to other types (interface or otherwise). In general, if you're using an interface, you should care only about that interface and nothing else.
But nothing's perfect and sometimes you want to be able to pass a reference around, treating it as one type sometimes, but being able to expand on that or get another interface from it other times. A delegate simply doesn't support that type of operation directly (you can look at the Target property for an element in a delegate's invocation list, but that's definitely awkward).
c) “The method being implemented is linked to the type or identity of
the class: for example, comparison methods. “
Are they implying that the reason for implementing IComparable
interface, you basically identify a class to the world as having
comparison methods? Or is the above quote implying something
completely different?
Well, implementing IComparable does do what you suggest. But I think the advice on MSDN goes farther than that. They are saying that the interface describes something intrinsic to the type. Using IComparable as an example, a type would implement that if there is a single, natural way to order instances of the type. Or consider IEnumerable, which a type would implement if there is a single, natural way to retrieve individual elements from the type (i.e. it's a collection).
Even for those interfaces, there are in fact often "alternate" implementations one might choose from for specific reasons. Thus we have the IComparer interface, and all the stuff in LINQ to rearrange, filter, etc. collections. But even accounting for those examples, types implementing IComparable and IEnumerable (for example) still have an obvious default behavior for those interfaces, and so they implement them.
Other types are not naturally comparable; any time you want to create an ordered collection of them, you want to choose specifically how to order them, and each time you might choose differently. So in those cases it makes more sense to provide for the code wanting to specify the order to pass a delegate that does the comparison, or implement a _different_ class that implements IComparer to do the work.
3)
Continuing with msdn article:
“One good example of using a single-method interface instead of a
delegate is IComparable Although using a delegate comparison method as
the basis of a sort algorithm would be valid, it is not ideal. Because
the ability to compare belongs to the class and the comparison
algorithm does not change at run time, a single-method interface is
ideal.”
a) “Because the ability to compare belongs to a class…” --> point they
are trying to make? So what if the ability belongs to a class? Why
would that make delegate less appropriate?
Because it's combined with the second half of that clause...
b) “…and the comparison algorithm does not change at run time, a
single-method interface is ideal.”
What has comparison algorithm not changing at run time got to do with
delegates and interfaces?
Because that makes it intrinsic to the class. Something that is intrinsic to a class and is implemented by the class is best represented as an interface. It would be clumsy to try to retrieve a delegate from the class, and in fact C# provides no well-defined way to do this (though of course you can create methods or properties to accomplish the goal).
On the other hand, an interface is a way to declare along with the type some specific behavior that the type has, regardless of what else is in it. To get that behavior, the calling code doesn't need to know anything at all about the type in question; it just needs to know about the interface that the type implements.
And besides, what do they mean with comparison algorithm not changing
at run time?
They mean that the comparison algorithm doesn't change at run-time. It's defined and set in stone at compile-time.
Pete
.
- Follow-Ups:
- Re: Delegates VS interfaces - some confusion
- From: beginwithl
- Re: Delegates VS interfaces - some confusion
- References:
- Delegates VS interfaces - some confusion
- From: beginwithl
- Delegates VS interfaces - some confusion
- Prev by Date: Re: how to get fractional digits from decimal?
- Next by Date: Re: how to get fractional digits from decimal?
- Previous by thread: Delegates VS interfaces - some confusion
- Next by thread: Re: Delegates VS interfaces - some confusion
- Index(es):
Relevant Pages
|
Loading
