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

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 2

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 3

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 4

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.