Wednesday, November 23, 2005 

Interfaces Vs. Delegates (or Events)

Languages influence thought processes and ultimately solutions. Therefore, the mere presence of a keyword or construct in a language tends to influence the way we think about problems when we use that language. Experience also influences the way we see problems and design solutions, so previous experience with a specific language tends do influence the way we approach new languages. I've seen this several times, as programmers moved from C to C++ ("should I use a struct or a class?"), from C++ to Java ("should I use an abstract class or an interface?"), and from all the others, including VB, to C# ("should I use an event/delegate or an interface?"). [Note: Events and delegates are different beasts, but similar enough for what I'm going to say that I will just talk about the delegate as a unified concept]. The Interface Vs. Delegate debate has come up several times during design sessions, and even during a short break in my latest lesson at University of Trieste.
Obviously, I'm not the first to write on this topic:
The Delegates Tutorial on MSDN has some guidelines (scroll near the end, "Delegates vs. Interfaces").
Anders Hejlsberg talks about design and performance issues in Delegates, Components, and Simplexity
Jon Shemitz talks about performance too in Delegates vs. Interfaces (this article has been web-published almost everywhere).
Don Box has some thoughts about design issues in Are delegates the moniker of .NET? (never mind the weird title :-). GotDotNet seems to have major problems :-), so here comes the Google Cache to the rescue (scroll down and you'll find it).
Overall, those articles draw a pretty confused picture :-))) so I'll throw in some colors myself :-). More seriously, sooner or later I'll publish something more comprehensive (and definitive :-) on the subject, but right now, I just want to add a few thoughts about design with interfaces Vs. delegates.
Interfaces and Delegates are both contracts. The implementer has to respect the syntactic contract (typing, and names when you use interfaces). The caller has a role in the contract too - I'll be back to this in a short while, as it makes a difference. Delegates are a "weaker" form of contract (Hejlsberg and Box both seem to agree on this point, although they use different words/metaphors). It is weaker because:
1) it does not group together a set of functions
2) it does not force the name of the method
3) it does not force the method to be a member
4) it does not give identity to the callee
I'll give attention only to (4) right now, because it has been somewhat ignored by other authors. When you implement an interface, and you pass a reference to that interface to someone, you're engaging in a contract which says: whenever you call one of those functions, the same object will handle the call [in different methods]. When you expose a set of delegates, you don't have that guarantee. Calls could be redirected to different objects. This breaks the idea of an interface as a whole contract, switching to a model of methods [delegates, actually] as individual contracts. For most people, that means additional freedom and is therefore welcome. However, the lack of an overall contract is not necessarily a good thing. An interface, in UML 2 speaking, may have an associated Protocol State Machine. A PSM is a behavioral contract, opposed to the syntactic contract most people think about. A behavioral contract is a constraint on both sides: the caller must call functions in a specified order, when the callee is in specified (although abstract) states. However, the contract makes sense because there is one, well determined receiver. You can't enforce a contract among a scattered group of delegates.
Bottom line: read the stuff linked above, but add this: if the concept you have in mind is a single contract, encompassing multiple functions, possibly with an associated PSM, use an interface. If you only have individual contracts in your mind, you can use delegates.
For more on PSM, my italian readers may want to read my UML 2 Manuale di Stile.
Comments:
This post has been removed by a blog administrator.
 
Post a Comment

<< Home