You've almost certainly written at least one callback function. Callback functions are functions you don't call...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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 a 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.
See the conclusion of this article at Informit.com for an example of this procedure.