Click here to Skip to main content
15,888,088 members
Please Sign up or sign in to vote.
1.00/5 (1 vote)
See more:
lets' say I have 2 buttons. Add & Substract.
I will write two seperate functions "Add" & "Substract" & i will call them accordingly on each button click.
Then why should I go for delegate when things are already known to me in advance which function to call on which button click ?

What I have tried:

I have tried implementing it via both normal function calling & also by implementing via delegate.
But i did not get the difference when to use delegate over normal function call.
Posted
Updated 2-Apr-16 10:45am

Delegates are used for more than just "call this or that" - they can provide a "chain of methods to be called" for example. You use delegates already, quite a bit - you just don't realize it because they are "hidden" at the core of Event handling!

One reason for a delegate based approach is it's flexibility: you don;t have to write code which "works out" which method to call:
C#
private DoIt(MyEnum functionType)
   {
   switch(functionType)
      {
      case MyEnum.Add: Add(); break;
      case MyEnum.Sub: Sub(); break;
      default: throw new ParameterException("Unknown function type: " + functionType);
      }
   }

C#
private DoIt(MyDelegate del)
   {
   if (del != null)
      {
      del();
      }
   }

When you add Mult and Div methods, you don't have to change the code in DoIt at all - you just pass the appropriate delegate and it all works transparently.

One example of this is a Sort method, when you pass a comparison delegate to compare UserNames, or a different delegate to compare BirthDates depending on what you want to sort - provided the methods match the delegate signature and return the right value (-1, 0, or +1) the sort will work without caring what it it actually comparing!
 
Share this answer
 
v2
Comments
Sascha Lefèvre 2-Apr-16 11:50am    
+5
Afzaal Ahmad Zeeshan 2-Apr-16 12:28pm    
Exactly. +5
Your logic is badly, badly flawed. You start from the point where there should not be any essential difference by definition, and then, based on that, draw a conclusion that there is no difference.

If you still did not get it, I'll explained on another example. This is like considering a microscope as a device for hammering in nails, but with a number of part of unknown purpose. This is your starting point in first place. Then you take it, hammer a nail, and conclude that if functions the same way as the hummer, and the unknown parts are not utilized in the process, so a question should be raised, "aren't they useless?"… This is exactly what you have done.

Actually, the delegate is one of the implementations of a very deep conception: methods as first-class objects. A delegate is an object, and unlike a method, its instance can be passed as a method argument or the type member reference, a property or a field. This way, this is another device of abstraction, along with, say, method parameter-passing or variable. This is how it explained in Wikipedia:
https://en.wikipedia.org/wiki/Delegation_%28programming%29[^],
First-class citizen — Wikipedia, the free encyclopedia[^].

I cannot blame you much in not understanding .NET delegates, specifically. Not many developers understand their full capacity. Unfortunately, this is because MSDN documentation, comprehensive in most parts, leave a lot of mystery about delegates and delegate instances; its help pages on the topic are closer to some cook-book recipes and leave important functionality, forget the mechanism, behind the scene.
Big part of it is described in one section of my article: Dynamic Method Dispather, 4.1. On the Nature of Delegate Instance.

—SA
 
Share this answer
 
v2

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900