Are delegates more than abbreviations?

Question

Let's pretend that:

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 drop Bar and Baz as Foos and call their Func methods.

Delegates simplify this a bit:

 delegate bool Foo(int x); bool Bar(int x) { return (x<0); } bool Baz(int x) { return (x>0); } 

Now we can throw around Bar and Baz as delegates to Foo.

What is the real use of delegates other than getting shorter code?

Answer 1

There is a slight difference, delegates can access the member variables of the classes in which they are defined. In C # (unlike Java), all inner classes are considered static. Therefore, if you use an interface to control callbacks, for example, an ActionListener for a button. The inner implementation class must be passed (via the constructor) with references to parts of the containing class with which it may need to interact during a callback. Delegates do not have this limitation, so they reduce the amount of code needed to implement a callback.

Shorter, more concise code is also a worthy advantage.

Answer 2

From the point of view of Software Engineering, you are right, delegates are very similar to functional interfaces because they are a prototype of a functional interface.

They can also be used in a variety of ways: instead of passing an entire class to the one that contains the method you need, you can only pass a delegate. This saves a lot of code and creates much more readable code.

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

Comparing the two is an interesting concept. Previously, I did not consider how similar the ideas from the use-case and the point of structuring the code are.

Answer 3

The delegate really has a lot to do with the interface reference, which has a single method from the perspective of the caller.

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

You cannot apply interface references only for any class that conforms to the interface agreement. The class must explicitly declare that it supports the interface. You can apply the delegate link to any method that matches the signature.

You cannot include static methods in an interface contract. (Although you can use static methods using extension methods). You can reference static methods using a delegate reference.

Answer 4

No, delegates are for pointers to methods. You can then verify that the signature of the method associated with the delegate is correct.

In addition, you do not need to know the structure of the class. That way, you can use the method you wrote to jump to the method in another class and determine the functionality that you want to execute.

Take a look at the List <class using the Find method . Now you can determine what determines if something is a match or not, without requiring the elements contained in the class to implement IListFindable or something like that.

Answer 5

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

Answer 6

You might think of delegates as an interface to a method that determines which arguments and return type should have a method suitable for the delegate

Answer 7

A delegate is a typed method pointer. This gives you more flexibility than interfaces, because you can use covariance and contravariance, and you can change the state of the object (you will have to pass this pointer using functors based on the interface).

In addition, delegates have a lot of nice syntactic sugar that allows you to do something like how easy it is to combine them.

Answer 8

Yes, a delegate can be thought of as a single method interface.

Answer 9

Interfaces and delegates are two completely different things, although I understand the temptation to describe delegates in terms similar to an interface for ease of understanding ... however, ignorance of the truth can lead to confusion along the line.

The delegates were inspired (in part) because the black art of method pointers in C ++ did not meet certain goals. A classic example is the implementation of a message passing or event processing mechanism. Delegates allow you to define a method signature without any knowledge of the types or interfaces of a class. I could define the delegate void eventHandler (Event * e) and call it on any class that implemented it.

For some understanding of this classic problem and why delegates are advised to read this and then this .

Answer 10

At least one suggestion for adding closures (i.e. anonymous delegates) to Java, they are equivalent to interfaces using a single member method.