Delegates vs. Interfaces in .NET
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
You've almost certainly written at least one callback function. Callback functions are functions you don't call directly. They're called, using a pointer, from within some library code that you do call directly, passing the callback function's address as a parameter. The odds aren't quite so high that you've written code that takes and uses callback parameters, but the odds aren't all that low, either, as this is also a fairly common task.
Sometimes, the callback is only called once, given access to a specific part of a monstrous or opaque data structure. More commonly, your callback is called many times, in the process of selecting items from a list, or telling library code when to stop looping.
Chances are, you probably prefer to write callback code that takes strongly typed parameters. That lets you be reasonably sure a non-null parameter is a pointer to a method with the right prototype, and not a pointer to a method with a different prototype, or even a pointer to data.
When it comes to writing .NET code that takes callback parameters, your first instinct may be to use delegates, which look a lot like strongly typed method pointers in C++ or Delphi. It may not occur to you that you can implement a callback parameter as an interface instead. Interfaces and delegates share the key property of allowing you to call a method with the right prototype without knowing which object implements the method, which instance is bound to the call, and even the name of the method you're calling.
Interface calls are faster than delegate calls. An interface reference is a reference to an instance of an object which implements the interface. An interface call is not that different from an ordinary virtual call to an method. A delegate reference, on the other hand, is a reference to a list of method pointers. While invoking a delegate looks like you're making an indirect call through a method pointer, it's actually a subroutine call that walks the list of method pointers. The overhead involved in making the call and walking the list means that delegate invocation can be two or three times slower than calling a method through an interface reference.
Interfaces are also a bit more general than are delegates. A single interface reference gives you access to all the methods of the interface. You can also check if the interface is implemented by This object type, or if the object also implements That other interface. If it does, you can cast the interface reference to an instance reference, or to a reference to another interface. Conversely, you can not go from a delegate to the instances it will call, or to any other methods those instances may support.
However, don't conclude from this that you should always implement callbacks via interfaces, not delegates. One key difference between delegates and interfaces is that you can create a delegate to any method with the right prototype.
However, you can only convert an instance reference to an interface reference if the object explicitly implements the interface. That is, while an object can “implement” an interface entirely with inherited methods, it is not enough for an object to support all the interface's methods. This means that you can't use an interface reference to callback to methods of value types or of sealed classes, unless they already support the interface.
For example, given
interface IToString
{
string ToString();
}
class Implementor: IToString
{
}
you can say
IToString Reference1 = new Implementor()
because the Implementor class implements IToString with the ToString method it inherits from System.Object. But you can't say
IToString Reference2 = new object()
because the System.Object class does not explicitly implement IToString.
In other words, callback code that takes delegate parameters can be a bit easier to use than callback code that takes interface parameters. You can create a delegate to any (reference or value type) object which has a method of the right signature. If you want to get an interface reference to an object which does have a method of the right signature but which doesn't explicitly support the right interface, you do have to create a subclass (like the Implementor class) which implements the interface with inherited methods.
This is not much of a limitation. Callback methods are often methods of the class that calls the code that does the callback, or perhaps they are methods of a small class nested within the class that calls the code that does the callback. It's easy for the author of the class that calls the code that does the callback to explicitly support a callback interface—and using a callback interface instead of a callback predicate means your code will be faster, especially if you call the callback many times.
In general, the only time you should use delegates for callbacks is when there is some chance that a user might want to pass a method of an existing sealed type.