I never seem to understand why we need delegates?
I know they are immutable reference types that hold reference of a method but why can't we just call the method directly, instead of calling it via a delegate?
Thanks
Simple answer: the code needing to perform the action doesn't know the method to call when it's written. You can only call the method directly if you know at compile-time which method to call, right? So if you want to abstract out the idea of "perform action X at the appropriate time" you need some representation of the action, so that the method calling the action doesn't need to know the exact implementation ahead of time.
For example:
Enumerable.Select in LINQ can't know the projection you want to use unless you tell it
The author of Button didn't know what you want the action to be when the user clicks on it
If a new Thread only ever did one thing, it would be pretty boring...
It may help you to think of delegates as being like single-method interfaces, but with a lot of language syntax to make them easy to use, and funky support for asynchronous execution and multicasting.
Of course you can call method directly on the object but consider following scenarios:
You want to call series of method by using single delegate without writing lot of method calls.
You want to implement event based system elegantly.
You want to call two methods same in signature but reside in different classes.
You want to pass method as a parameter.
You don't want to write lot of polymorphic code like in LINQ , you can provide lot of implementation to the Select method.
Because you may not have the method written yet, or you have designed your class in such a way that a user of it can decide what method (that user wrote) the user wants your class to execute.
They also make certain designs cleaner (for example, instead of a switch statement where you call different methods, you call the delegate passed in) and easier to understand and allow for extending your code without changing it (think OCP).
Delegates are also the basis of the eventing system - writing and registering event handlers without delegates would be much harder than it is with them.
See the different Action and Func delegates in Linq - it would hardly be as useful without them.
Having said that, no one forces you to use delegates.
Delegates supports Events
Delegates give your program a way to execute methods without having to know precisely what those methods are at compile time
Anything that can be done with delegates can be done without them, but delegates provide a much cleaner way of doing them. If one didn't have delegates, one would have to define an interface or abstract base class for every possible function signature containing a function Invoke(appropriate parameters), and define a class for each function which was to be callable by pseudo-delegates. That class would inherit the appropriate interface for the function's signature, would contain a reference to the class containing the function it was supposed to represent, and a method implementing Invoke(appropriate parameters) which would call the appropriate function in the class to which it holds a reference. If class Foo has two methods Foo1 and Foo2, both taking a single parameter, both of which can be called by pseudo-delegates, there would be two extra classes created, one for each method.
Without compiler support for this technique, the source code would have to be pretty heinous. If the compiler could auto-generate the proper nested classes, though, things could be pretty clean. Dispatch speed for pseudo-delegates would probably generally be slower than with conventional delegates, but if pseudo-delegates were an interface rather than an abstract base class, a class which only needs to make a pseudo-delegate for one method of a given signature could implement the appropriate pseudo-delegate interface itself; the class instance could then be passed to any code expecting a pseudo-delegate of that signature, avoiding any need to create an extra object. Further, while the number of classes one would need when using pseudo-delegates would be greater than when using "real" delegates, each pseudo-delegate would only need to hold a single object instance.
Think of C/C++ function pointers, and how you treat javascript event-handling functions as "data" and pass them around. In Delphi language also there is procedural type.
Behind the scenes, C# delegate and lambda expressions, and all those things are essentially the same idea: code as data. And this constitutes the very basis for functional programming.
You asked for an example of why you would pass a function as a parameter, I have a perfect one and thought it might help you understand, it is pretty academic but shows a use. Say you have a ListResults() method and getFromCache() method. Rather then have lots of checks if the cache is null etc. you can just pass any method to getCache and then only invoke it if the cache is empty inside the getFromCache method:
_cacher.GetFromCache(delegate { return ListResults(); }, "ListResults");
public IEnumerable<T> GetFromCache(MethodForCache item, string key, int minutesToCache = 5)
{
var cache = _cacheProvider.GetCachedItem(key);
//you could even have a UseCache bool here for central control
if (cache == null)
{
//you could put timings, logging etc. here instead of all over your code
cache = item.Invoke();
_cacheProvider.AddCachedItem(cache, key, minutesToCache);
}
return cache;
}
You can think of them as a construct similar with pointers to functions in C/C++. But they are more than that in C#. Details.
Related
I have a large amount of code that is dependent on a list of objects. the list is modified a lot while being passed around as a parameter to various methods.
Even though I understand the workings of this code, I feel uneasy letting such an easy opportunity to make a mistake exist. Is there a way to handle this situation in c# outside of a goofy comment or refactoring?
If you are passing a List<Something> around in your code, then it is "mutable" by default, and there is no way to signal this explicitly.
If this is a language background issue (Haskell?), then in C# you should looks things from a different perspective: if you wanted to pass around an immutable collection, you would need to use some different type (maybe an IEnumerable<Something>, even if it's not the same as a list); if you're passing around a List, instead, it can be modified by every method that receives it.
Maybe you can give that list a special type:
class MyCustomMutableList : List<int>
You could even not give it any base class to make sure that any usage site must use this special type in order to be able to access list data.
I would normally consider this a misuse of inheritance. If this is an implementation detail and does not leak out to consumers of your API it's probably good enough. Otherwise, create an IList<int> derived class through composition. R# has a feature to delegate all virtual methods to an instance field. That generates all that code.
You also could create a wrapper class that just exposes the required methods to perform the required mutations:
class DataCollector {
public void Add(int item) { ... }
}
Since all this object allows to do is mutation it is pretty clear that mutation is going on.
Is there any way, without using Reflection, of writing something along the lines of OSteele's Functional Invoke in C#?
This means using it as in:
Action<T> MethodName = StaticUtil.Invoke<T>("MethodName", optionalCurriedArgs);
And then calling:
MethodName(objWithMethodName);
I know using a Lambda would do the trick.
What I mean, is using something along the lines of AS3's:
public static function invoke( selectedMethod : String, ... arguments ) : Function {
var args : Array = arguments.slice();
return function ( object : * ) : * {
return object[ selectedMethod ].apply( object, args);
};
}
Thank you for reading.
No. There is no obvious way in C# without using Reflection to call a function on a particular class. At best you might try dynamic and let it be resolved at runtime. You can try using a library like FasterFlect to solve your need.
Alternatively, if you want a built in method you can do
typeof(MyObject).InvokeMember(methodName
,BindingFlags.Public | BindingFlags.Instance
,null
,myInstance
,new object[]{parameter1,parameter2})
I would be lying to you if I said it wasn't reflection though. The CLR wasn't designed for you to invoke methods dynamically like javascript. This was a conscious decision to make a high performance method call. If you need to pass functions around use Delegates. If your method needs variable argument support you can use overloads, or params. If you need to call methods dynamically via strings:
use Dictionary<string,DelegateType> or if you know you have a few methods and need absolute speed use a List<Tuple<string,DelegateType>>. If you have many types that all respond to a message use Interfaces. If the classes aren't your own, or they are specialized for primitives try dynamic.
C# is a well designed language written for standard coding practices. There are lots of options. If you really need to they give you the tools to look up members and invoke them. Reflection is slow because the CLR was designed to be SAFE first. If you find yourself needing lots of reflection dynamic invocation you might want to reconsider your design choices. If you still can find no other way you can still use caching and Delegates to make that fast. dynamic is entirely done with clever caching and delegates, and dynamic in the best cases is nearly as fast as native code.
In theory, you can create a pattern like CallSite<T> in the DLR to fast cache a particular call site. I do something similar in a dynamic proxy I wrote to get around the fact that there is no way to create a function pointer to an open generic method. (e.g. I wanted to have a mydelegate.Invoke<T>(T arg) ).
I think the title is kinda hard to understand. That's why I will try to explain myself a bit more clearly:
I have a ClickLabel which is supposed to implement a certain method that can be passed as a parameter during its construction or later on to perform a certain action.
The point is that not each ClickLabel I will be implementing is supposed to execute the same task.
I might just be too tired right now to solve the thing on my own but I wanted to get some professional answers from you as to how I can solve this as easily as possible because I know that otherwise it will haunt me forever.
if I got you right you should pass a delegate as a parameter and then assign it as event handler to ClickLabel
Sounds like you need to create an IClickLabel interface that defines the method that you want to execute then you can define different classes that implement IClickLabel. The param on your constructor would be of Type IClickLabel which ensures that each class you pass in has the required method available to call - and each class implementing IClackLabel can implement the logic in the method differently.
Why are they termed differently?
Isn't the nature/purpose/place of a function identical to that of a method?
Functions stand alone and methods are members of a class. That's all. (it's really all the same.)
A method is a function that is attached to an object.
JavaScript functions are usually referred to as methods when used in the context of an object.
e.g. document.getElementById('foo') uses the getElementById method.
Function is a very old term meaning a segment of code that accomplishes some task (does some function, if you will).
Method is a relatively newer term (came with OO programming) that means a function that belongs to a specific instance of an object.
All methods are functions, but not all functions are methods.
See this related question from the programmers stackexchange.
You usually find the term function when dealing with procedural code. OOP uses the term method but they are the same thing.
A function is a piece of code that is called by name. It can be passed data to operate on (ie. the parameters) and can optionally return data (the return value).
All data that is passed to a function is explicitly passed.
A method is a piece of code that is called by name that is associated with an object. In most respects it is identical to a function except for two key differences.
It is implicitly passed the object for which it was called
It is able to operate on data that is contained within the class (remembering that an object is an instance of a class - the class is the definition, the object is an instance of that data)
Also, another answer: Difference between function and method?
Well, its all about the names, but generally functions and methods are the same thing, and of course have the same purpose.
It all began with the first programming languages, where they where called functions, but as more higher level programming languages arose, i guess they thought to name them methods even if they are and serve the sasme purpose.
EDIT:
Functions are not part of any object or class.
Methods are a memeber of an object or class.
This question already has answers here:
Closed 13 years ago.
Possible Duplicates:
Delegate Usage : Business Applications
Where do I use delegates?
Hi,
I'm new to the concept of a delegate in .NET - I haven't really used them yet and think they are probably there for a good reason - when should I be using a delegate?
Examples are very welcome.
Delegates provide a way for you to pass behavior as a parameter.
Common examples are Events and asynchronous programming where something other than your object is responsible for calling into your object. You provide that event with a delegate, and now it's able to run the behavior associated with that delegate.
This can also be a useful technique when implementing a general algorithm. There've been times where I'm writing multiple methods that are very similar. Perhaps they loop over the same set of data, but they perform slightly different tasks. I can pass in a delegate to a single function to perform that task, then call the delegate from inside the loop over the data. This way I don't have to implement the loop over the data multiple times, I only have to write new code that does new things-- the common behavior is all captured in a common way.
In response to the comment:
The difference between calling the delegate from within the loop and calling the method from within the loop is that the delegate is a parameter to the function that contains the loop. This means that that function could do anything, not just what's defined within a particular method. That flexibility can and has been leveraged to supply generic algorithms in libraries completely independent of the specifics of what the algorithms are working with. Linq is a fine example of the generality that is allowed via the flexibility of delegates.
Delegates are useful when you need to tell another piece of code how to do something. Events are the simplest example - separating the event (something happened) from how to handle it. Other examples are some common iterative operations, such as a custom find:
List<Foo> foos = new List<Foo>();
foos.Find(delegate(Foo foo)
{
if(foo.CustomProperty.Contains("special value"))
{
return false;
}
return true;
});
The above is a totally arbitrary example but makes the point that you can separate the what (iterating and running a "find" criteria) from the how (how to determine whether something is found).
Also, I would recommend using generic delegate types instead of creating your own. Examples below:
EventHandler< TEventArgs>
Func< TResult>
Func< T1, T2, TResult>
Func etc...
Action< T1>
Action< T1, T2>
Action etc...
Events use delegates behind the scenes.
If you use events you've used delegates but just with a nicer syntax.
Basically one use for them is for callbacks or event based programming.
Delegates are used for event driven programming. Best practices are often about decoupling code (or 'loose' coupling). Using delegates you can subscribe methods to events, instead of having X call Y if something happens, and then Y call Z under a certain condition and so forth.
Events and Callbacks in the .NET guidelines explains it well.
In summary, you should prefer events in simple APIs because there is strong IDE support and most developers are comfortable with events. However, if you need the user to provide code that will be executed, you should consider using delegates or virtual members. Callbacks are less performant, but if you use delegates like Action and Func you allow lambdas.
Example case: a single resource is being used by multiple objects. The resource needs an asynchronous callback to these objects, but the nature of the resource demands that only one request be active at a given time, and that request is tied to a particular object. Due to the architecture, I don't want to pass the objects into the resource, so instead, I send the resource a delegate from each object and store these delegates along with object identifiers. When a request is made, I can look up the corresponding object identifier and call its specific delegate.
I originally implemented this with an event, but since the event couldn't be 'aimed' at a particular object, I was having issues. I'm not sure this is best practice, but it seems to work well for me.