Are delegates not just shorthand interfaces?

Question

Suppose we have:

interface Foo 
{
 bool Func(int x);
}

class Bar: Foo
{
  bool Func(int x)
  {
   return (x>0);
  }  
}

class Baz: Foo
{
  bool Func(int x)
  {
   return (x<0);
  }  
}

Now we can toss around Bar and Baz as a Foos and call their Func methods.

Delegates simplify this a little bit:

delegate bool Foo(int x);

bool Bar(int x)
{
 return (x<0);
}

bool Baz(int x)
{
 return (x>0);
}

Now we can toss around Bar and Baz as Foo delegates.

What is the real benefit of delegates, except for getting shorter code?

Answer 1

No, delegates are for method pointers. Then you can make sure that the signature of the method associated w/ the delegate is correct.

Also, then you don't need to know the structure of the class. This way, you can use a method that you have written to pass into a method in another class, and define the functionality you want to have happen.

Take a look at the List<> class with the Find method. Now you get to define what determines if something is a match or not, without requiring items contained in the class to implement IListFindable or something similar.

Answer 2

You can pass delegates as parameters in functions (Ok technically delegates become objects when compiled, but that's not the point here). You could pass an object as a parameter (obviously), but then you are tying that type of object to the function as a parameter. With delegates you can pass any function to execute in the code that has the same signature regardless of where it comes from.

Answer 3

A delegate is a typed method pointer. This gives you more flexibility than interfaces because you can take advantage of covariance and contravariance, and you can modify object state (you'd have to pass the this pointer around with interface based functors).

Also, delegates have lots of nice syntactic sugar which allows you to do things like combine them together easily.

Answer 4

One can think of delegates as an interface for a method which defines what arguments and return type a method must have to fit the delegate

Answer 5

Yes, a delegate can be thought of as an interface with one method.

Answer 6

There is a slight difference, delegates can access the member variables of classes in which, they are defined. In C# (unlike Java) all inner class are consider to be static. Therefore if you are using an interface to manage a callback, e.g. an ActionListener for a button. The implementing inner class needs to be passed (via the constructor) references to the parts of the containing class that it may need to interact with during the callback. Delegates do not have this restriction therefore reduces the amount of code required to implement the callback.

Shorter, more concise code is also a worthy benefit.

Answer 7

From a Software Engineering perspective you are right, delegates are much like function interfaces in that they prototype a function interface.

They can also be used much in the same kind of way: instead of passing a whole class in that contains the method you need you can pass in just a delegate. This saves a whole lot of code and creates much more readable code.

Moreover, with the advent of lambda expressions they can now also be defined easily on fly which is a huge bonus. While it is POSSIBLE to build classes on the fly in C#, it's really a huge pain in the butt.

Comparing the two is an interesting concept. I hadn't previously considered how much alike the ideas are from a use case and code structuring standpoint.

Answer 8

A delegate does share a lot in common with a interface reference that has a single method from the caller's point of view.

In the first example, Baz and Bar are classes, which can be inherited and instantiated. In the second example, Baz and Bar are methods.

You can't apply interface references to just any class that matches the interface contract. The class must explicitly declare that it supports the interface. You can apply a delegate reference to any method that matches the signature.

You can't include static methods in an interface's contract. (Although you can bolt static methods on with extension methods). You can refer to static methods with a delegate reference.

Answer 9

Interfaces and delegates are two utterly different things, although I understand the temptation to describe delegates in interface-like terms for ease of understanding...however, not knowing the truth may lead to confusion down the line.

Delegates were inspired (partly) because of the black art of C++ method pointers being inadequate for certain purposes. A classic example is implementing a message-passing or event-handling mechanism. Delegates allow you to define a method signature without any knowledge of a class' types or interfaces - I could define a "void eventHandler(Event* e)" delegate and invoke it on any class that implemented it.

For some insight into this classic problem, and why delegates are desirable read this and then this.

Answer 10

In at least one proposal for adding closures (i.e. anonymous delegates) to Java, they are equivalent to interfaces with a single member method.