Why does the MSDN site compare using delegates and interfaces?

The MSDN site compares using delegates instead of an interface, but what makes these two language-level construct开发者_如何学Pythons so similar that one could be used over another? They seem to do completely different things?

Thanks

One can view a delegate as equivalent to an interface with a single method. In languages where delegates are not supported, patterns for which one would normally use delegates are often written using interfaces instead.

For example, Java uses anonymous inner classes that implement interfaces where one would normally use an anonymous delegate / lambda expression in C#:

Java:

// anonymous inner class that implements an interface
Runnable runnable = new Runnable()
                       { 
                           public void run()
                           { 
                             System.out.println("Hello world"); 
                           } 
                       });

Thread thread = new Thread(runnable);

C#:

// lambda expression convertible to a delegate-type
ThreadStart ts = () => Console.WriteLine("Hello world");

 Thread thread = new Thread(ts);

In both cases, the intent is to provide a thread with an entry-point. One approach uses an interface, and the other, a delegate, but if you disregard the "plumbing", it's clear that interface is serving the same purpose as the delegate. Note that availability to use a lambda-expression to express this idea is not exclusive to delegates. Project Lambda for Java attempts to, amongst other things, bring conversion from a "function of the appropriate type to an anonymous instance of an interface or abstract class which declare just one method." This may eventually allow for the same terse syntax as the C# version, but without necessarily requiring delegate-types.

Even within the .NET framework, there are equivalences between interface-types and delegate-types, for example Comparison<T> and IComparer<T>.

EDIT: Updated code and made distinction clearer.

The aspect where delegates and interfaces are similar is in the situations where you need a callback ability but you do not want to introduce a dependency. To put it in more concrete terms with ClassA and ClassB you want the ability for ClassB to talk to ClassA but you do not want to introduce a dependecy where ClassB depends on ClassA.

In terms of delegates this is typically done via events. ClassB would define an event (which would be based on a delegate) and ClassA would bind itself to the event by building a delegate bound to one of its methods and then combind the delegate with the delegate in ClassB. When ClassB wanted to communicate with ClassA it would simply invoke the delegate associated with the event.

In terms of interfaces ClassA would implement an interface (call it IClassA) and pass itself to ClassB as an implementation of IClassA. So when ClassB wanted to talk to ClassA it would do so by invoking methods defined in the interface IClassA.

In both cases ClassB is not aware of the existence of ClassA but ClassB is nevertheless able to communicate with ClassA.