I think that I conceptually understand C# delegates, however, I am struggling to find a real world example where they would be useful. Can you provide some answers detailing how C# delegates were used in real applications and what problems they enabled you to get around.
|
|
GUI code uses delegates to handle events, such as button clicks, window moves. Using the delegate allows you do have a function called whenever the event occurs. An example would be linking a function that saves data to a "Save" button on the interface. When the button gets clicked it is set up to execute the function that saves data. It's useful in GUI programming because your whole program could be waiting for the user to do something and you have no way of knowing what they will do first. Using delegates allows the functionality of your program to be connected to the UI in such a way that the user can do things in any way they want. |
|||||
|
|
Virtually anything using the Observer Pattern would likely implement delegates. Read the description and you'll probably imagine some scenarios where you would use them. GUI event handling is a common example. |
|||
|
|
Linq uses the These allow you to use lambda expressions as parameters and define the action to be taken as part of the parameter list. |
|||
|
|
|
Delegates are bloody useful in asynchronous programming. You have a class which does stuff asynchronously and has a callback. You can have the delegate method invoked upon callback - and your class implementation will do the logic described in your delegate method. |
|||
|
|
|
Delegates are particularly useful as a solution for the hole in the middle pattern. Essentially, there are a lot of cases where you want to wrap a unique set of instructions inside of a common bunch of instructions. It's particularly difficult if the instructions before and after the unique bit need to share state. With delegates, you can just pass a delegate into a function. The function executes the before bit, executes the delegate, then executes the after bit. |
|||
|
|
|
In the "old days" of non-OOP languages like Fortran and C, it was incredibly useful to be able to have a subroutine receive an argument which was a pointer to a function.
For example, the In windowing systems, all kinds of callbacks follow the same pattern. In Lisp, even in the early days, there was something called a "functional argument" or FUNARG, which was not only a function, but it also contained a storage context where it could remember and interact with part of the outside world. This same need exists in OOP languages, except when you pass the address of a function you also have to pass the address of the object the function is a method of. That's two things you have to pass. So a delegate is just that, and allows that good old pattern to still be used. |
||||
|
|
|
Here is a simple example that shows how useful delegates can be at creating simple code that follows the DRY principle. It also allows you to keep code extremely close to where it is needed.
Here is a real world example of the advantage that delegates provide.
|
||||
|
|
|
I've seen interesting implementations of the Strategy pattern that uses delegates effectively. (ie the strategy is a delegate) The one I was looking at was for pathfinding where the algorithm to find the path was a delegate that could be (re)assigned to at runtime so that different algorithms could be used (BFS vs A* etc.) |
|||
|
|
|
Many of the classic GoF patterns can be implemented with delegates: For example, Command pattern, Visitor pattern, Strategy pattern, Factory pattern and Observer pattern can often be implemented with a simple delegate. Sometimes, a class is better (e.g. when a command needs a name or a strategy object needs to be serialized) but in most cases, using |
|||
|
|
|
My first encounter with delegates was checking for a program update (windows forms C# 3.5) by downloading a file from my website, but to avoid the update checking locking the whole program I used a delegate and a thread to do it asynchronously. |
|||
|
|