Related
I'm new to C#, I'm very confused with the terms used like 'listener', 'caller', 'callback', 'EventHandler', let's say we have the following code below:
public class Car
{
public delegate void CarEngineHandler();
public CarEngineHandler listOfHandlers;
public void Accelerate(int delta)
{
if (delta > 80)
listOfHandlers(); // not checking null for simplicity
}
}
class Program
{
static void Main(string[] args)
{
Car myCar = new Car();
myCar.listOfHandlers = new Car.CarEngineHandler(CallWhenExploded);
myCar.Accelerate(120);
}
static void CallWhenExploded()
{
Console.WriteLine("Sorry, this car is dead...");
}
}
so in this scenario:
Who is the caller?
Who is the listener? listen to what?
Who is the callback?
Who is the EventHandler?
and my answer is:
The caller is myCar
not sure
The callback is CallWhenExploded() static function
EventHandler is listOfHandlers
am I correct? I really don't know who is the listener and listen to what.
Hopefully you understand that an variable of type string is like a bucket that holds a string of characters, and you can look at them individually, pass them round as a collection etc. It's quite an easy thing to visualize, this variable being a container that stores data, because we store data all the time in the real world; pieces of paper in a box/file etc
Delegates are like variables for methods - and this is a much harder concept to understand, that we can pass a method round as though it were just like data, and we can get the computer to run the method.. but that's what a delegate is. When you declare a delegate, it's like when you declare your own class:
delegate void SomeMethod(); //specify a delegate
class Person{ //specify a class
string FirstName;
string LastName;
}
Just like when you make a class, you're giving yourself the ability to create an instance of that class, when you declare a delegate you're giving yourself the ability to create an instance of that delegate. Your class instance refers to data, like here the first and last name of the person. A delegate instance refers to a method rather than referring to data. You can make one class instance that refers to "John" and "Smith". You can make a delegate instance that refers to Method1(). You can make another class instance that refers to "Bill" "Jones". You can make another delegate instance that refers to Method2().
You can associate any method with your delegate instance, so long as the method has a signature that is equal to the delegate. That delegate above will accept a reference to any method that takes no parameters and returns void. If you've got one or more of these kind of methods you can attach them to an instance of the delegate, pass the delegate instance like a variable, and the thing you've passed the delegate to can call the methods without needing to know what the method name is or anything about it.
Why would we want to do this? One major use of delegates is in event handling. Microsoft created UI controls that are capable of doing things - buttons you can click on. You'll want your button to do something when it's clicked, but everyone in the world will want their button to do something different when it's clicked, so Microsoft can't write the code for that. They can however say that they will make a button that takes a delegate (a method passed like a variable) and the button promises to call the method when it is clicked. You supply the code that does what you want, as a delegate, to the button. Your method has to have a certain signature (arguments) because the button wants to pass your method some data that may be helpful to you; perhaps the location of the mouse when the clock occurred, or the number of times it was clicked. UI components have hundreds of different kinds of events, they all run on delegates
Another good example of delegates is in the old style of async programming when we had Begin/End pairs of methods, calling Begin would typically start a new thread off doing something and we would have to supply a method (our method) to it that, when Microsoft's Begin method had finished doing something it would call our method to let us know it was done. Typically then our code would call End, passing in some reference our method had been given, and we'd get the result. Sending a request to a server would take some time, for example, so we'd Begin it, go do some other things, and when the response was ready we would be notified by our delegate being called and we would process the result
So, get used to the notion that a delegate is just a way or referring to a method, you pass it around, what you pass it to can run it and provide data to it without having a clue what it does. In terminology it is also referred to as a callback - the thing that will be called when the foreign method is done with its work, though it's a fairly loose term - it might be used to refer to either your method that does the work, or the instance of a delegate pointing to your method, the thing that is passed in. Effectively they're equivalent dependi on the context of the conversation
A delegate itself is more like a collection/array - you can attach multiple methods to it and when the delegate is called they will all run, though not in any defined order. In your example you assigned just one to it but it could be multiple:
SomeMethod delegs = null;
delegs += new SomeMethod(MyMethod1);
delegs += new SomeMethod(MyMethod2);
Invoking that delegate will cause both MyMethod1 and MyMethod2 to be run, possibly in 2,1 order
Events are delegates too, but they're a slightly special case, touched on above with the button click handler. When a delegate is specified with the event keyword it can only be invoked inside the class that declared the delegate variable. UI controls use this to ensure that only they can run the delegate; you can't reach into a button and force run its clock handlers yourself because the delegate list that handles a click is declared as an event. If you want to programmatically cause a button to fire its event handler list you normally have to subclass it so your code becomes operationally "inside" the button code
Listener as a phrase is more often associated with events but it's reasonably synonymous with callback and eventhandler - when you add a listener to an event, you're saying that you're writing code that will handle the occurrence of the event, your code (as a delegate/event handler) that acts when the event occurs. It doesn't "listen" per se; it just hangs around and gets kicked into action when the thing raising the event invokes the list of delegates/eventhandlers associated with the event.
As an aside, because delegate instances represent a variable that points to a method, i.e. they point to an action, your naming of the instances should be a verb, not a noun. You called yours listOfHandlers but it would have been more helpful to your understanding to call the delegate instance after the event/action that is occurring. The use case you were applying was one of overrevving so perhaps you should name it CarEngineOverRevving. You could have another for when the temperature exceeds. If both these delegates has the same signature (you want people who will handle these events to do so via a method with no arguments) then you can reuse the same delegate for the different events:
public void delegate CarEngineProblemHandler();
public CarEngineProblemHandler CarEngineOverRevving = null;
public CarEngineProblemHandler CarEngineOverheating = null;
The delegate is your way of declaring what you want the methods provided to you, that you will call, to look like. The list of named problems is what you are declaring other people can provide some handling for. I could decide to not give you a handler for overrevving because I will never do it, but overheating might happen anyway so I'll certainly give you a handler/listener/delegate/callback to call of it ever happens
You should be able to answer those questions when you understand 'broadcaster/subscriber' pattern used by delegates. 'broadcaster' holds the delegate instance and decides when to call target methods in its 'invocation list'. These target methods are the 'subscribers' and they can decide when to stop or start 'listening' by calling '-=' or '+=' on broadcaster's delegate field.
public class Car
{
// This is the 'delegate type'
// ‘Delegate type’ is what is responsible for defining the method such as its signature
// which include return type and parameters
// In this ‘Delegate type’ named:'CarEngineHandler', the return type is 'void' and there are no parameters
public delegate void CarEngineHandler();
//this is the ‘Delegate instance’
//‘Delegate instance’ is responsible for holding the reference to the actual methods
//that adheres to the delegate type.
//Delegate instance can be used to then ‘invoke’ that method whenever needed.
public CarEngineHandler listOfHandlers;
public void Accelerate(int delta)
{
if (delta > 80)
//this is where you use the 'Delegate instance' to ‘invoke’ the methods
// You can also you use: listOfHandlers.Invoke();
// which is same as calling 'listOfHandlers();'
// When delegate instance is invoked, all its actions in its invocation list are executed in order
//In this example it will first dispaly: "Sorry, this car is dead..."
// then display: "Calling, emergency..."
listOfHandlers(); // not checking null for simplicity
}
}
class Program
{
static void Main(string[] args)
{
Car myCar = new Car();
//This is where you add to the 'delegate instance', the 'target method's' that matches delegate signature
//A 'delegate instance' can contain more than one action. This list of actions is called the “invocation list”.
//You can also add multiple methods to invocation list like this: myCar.listOfHandlers += CallWhenExploded;
myCar.listOfHandlers = new Car.CarEngineHandler(CallWhenExploded);
// For example you can add another target method like this:
myCar.listOfHandlers += CallEmergencyService;
// you get details about the 'target methods' attached to the “invocation list” like this:
var listOfTargets = myCar.listOfHandlers.GetInvocationList();
Console.WriteLine(listOfTargets[0].Method.Name);
myCar.Accelerate(120);
}
static void CallWhenExploded()
{
Console.WriteLine("Sorry, this car is dead...");
}
static void CallEmergencyService()
{
Console.WriteLine("Calling, emergency...");
}
}
In C# in depth (an excellent book thus far), Skeet explains events aren't fields. I read this section many times and I don't understand why the distinction makes any difference.
I am one of those developers that confuse events and delegate instances. In my mind, they are the same. Aren't both just a form of indirection? We can multicast both. An event is setup as a field as shorthand...sure. But, we are adding or removing handlers. Stacking them up to be called when the event fires. Don't we do the same thing with delegates, stack them up and call invoke?
The other answers are basically correct, but here's another way to look at it:
I am one of those developers that confuse events and delegate instances. In my mind, they are the same.
An old saying about not seeing the forest for the trees comes to mind. The distinction that I make is that events are at a higher "semantic level" than a field of delegate instance. An event tells the consumer of the type "hi there, I am a type that likes to tell you when something happens". The type sources an event; that's part of its public contract.
How, as an implementation detail, that class chooses to keep track of who is interested in listening to that event, and what and when to tell the subscribers that the event is happening, is the business of the class. It happens to typically do so with a multicast delegate, but that's an implementation detail. It is such a common implementation detail that it is reasonable to confuse the two, but we really do have two different things: a public surface, and a private implementation detail.
Similarly, properties describe the semantics of an object: a customer has a name, so a Customer class has a Name property. You might say that "their name" is a property of a customer, but you would never say that "their name" is a field of a customer; that's an implementation detail of a particular class, not a fact about the business semantics. That a property is typically implemented as a field is a private detail of the class mechanics.
Properties aren't fields either, although they feel like them. They are actually a pair of methods (getter and setter) with special syntax.
Events are similarly a pair of methods (subscribe and unsubscribe) with special syntax.
In both cases, you usually have a private "backing field" inside your class, which holds the value manipulated by the getter/setter/subscribe/unsubscribe methods. And there's an auto-implemented syntax for both properties and events where the compiler generates the backing field and accessor methods for you.
The purpose is also the same: Properties provide restricted access to a field, where some validation logic is run before storing a new value. And an event provides restricted access to a delegate field, where consumers can only subscribe or unsubscribe, not read the list of subscribers, nor replace the whole list at once.
Let's consider the two ways to declare events.
Either you declare an event using an explicit add/remove method, or you declare an event without such methods.
In other words, you declare the event like this:
public event EventHandlerType EventName
{
add
{
// some code here
}
remove
{
// some code here
}
}
or you declare it like this:
public event EventHandlerType EventName;
The thing is, in some ways they're the same thing, and in other ways, they're completely different.
From the perspective of outside code, that is ... code outside of the class publishing the event, they're the exact same thing. To subscribe to an event, you call a method. To unsubscribe, you call a different method.
The difference is that in the second example code above, those methods will be provided by the compiler for you, however, that's still how it's going to be. To subscribe to the event, you call a method.
The syntax to do so, in C#, however, is the same, you do either:
objectInstance.EventName += ...;
or:
objectInstance.EventName -= ...;
So from the "outside perspective", the two ways are no different at all.
However, inside the class, there is a difference.
If you try to access the EventNameidentifier inside the class, you're actually referring to the field that backs the property, but only if you use the syntax that doesn't explicitly declare an add/remove method.
A typical pattern is like this:
public event EventHandlerType EventName;
protected void OnEventName()
{
var evt = EventName;
if (evt != null)
evt(this, EventArgs.Empty);
}
In this case, when you're referring to EventName, you're actually referring to the field that holds the delegate of type EventHandlerType.
However, if you've explicitly declared the add/remove methods, referring to the EventName identifier inside the class will be just like outside of the class, since the compiler cannot guarantee that it knows the field, or any other mechanism, in which you store the subscription.
An event is an accessor for a delegate. Just like a property is an accessor for a field. With the exact same utility, it prevents code from messing with the delegate object. Like a property has a get and set accessor, an event has the add and remove accessor.
It does behave somewhat different from a property, if you don't write the add and remove accessors yourself then the compiler auto-generates them. Including a private backing field that stores the delegate object. Similar to an automatic property.
You don't do this often but it is certainly not unusual. The .NET framework pretty commonly does so, for example the events of the Winforms controls are stored in an EventHandlerList and the add/remove accessors manipulate that list through its AddHandler() and RemoveHandler() methods. With the advantage that all the events (there are many) require only a single field in the class.
I can add to the former answers that delegates can be declared inside a namespace scope (outside a class) and events can be declared only inside a class.
This is because delegate is a class!
Another distinction is that , for events, the containing class is the only one that can fire it.
You can subscribe/unsubscribe to it via the containing class, but can't fire it (in contrast to delegates).
So maybe you can understand now why the convention is to wrap it inside a protected virtual OnSomething(object sender, EventArgs e). It is for the descendants to be able to override the implementation of the firing.
Most .NET stock events are have this signature:
delegate void SomethingSomething(SomethingEventArgs e);
event SomethingSomething OnSomethingSomething;
and
class SomethingEventArgs
{
public string Name;
public int Index;
public double Groar;
}
Why is that better (obviously is, otherwise anyone would choose to do) than:
delegate void SomethingSomething(string Name, int Index, double Groar);
event SomethingSomething OnSomethingSomething;
since you don't have to pack your parameters to an object, and without initializers (.NET 2.0) it was kind of typing exercise.
One reason that comes to mind is that you can return your values simpler when having them packed in an object - ie. handler can modify a member of the object. However, with multicast events, that can't always be good anyway.
So, why?
Read about Open/Closed principle.
By using a class, all inherited classes can introduce extra functionality without having to change the delegate signature. They can simply introduce a new event class (ExtendedEventArgs) which inherits yours (SomeEventArgs).
The main reason is that it is more maintainable. If you pass an objects and any of the properties change, you only have to modify that. If you pass variables, that is a lot more work. So, the code gets more maintainable and more readable this way.
A quote from Microsoft's Code Complete:
Limit the number of a routine’s parameters to about seven. Seven is a
magic number for people’s comprehension. Psychological research has
found that people generally cannot keep track of more than about seven
chunks of information at once (Miller 1956). This discovery has been
applied to an enormous number of disciplines, and it seems safe to
conjecture that most people can’t keep track of more than about seven
routine parameters at once.
In practice, how much you can limit the
number of parameters depends on how your language handles complex data
types. If you program in a modern language that supports structured
data, you can pass a composite data type containing 13 fields and
think of it as one mental “chunk” of data. If you program in a more
primitive language, you might need to pass all 13 fields individually,
If you find yourself consistently passing more than a few arguments,
the coupling among your routines is too tight. Design the routine or
group of routines to reduce the coupling. 1f you are passing the same
data to many different routines, group the routines into a class and
treat the frequently used data as class data.
Quoted text from the original post's image
The reason for this is to avoid breaking changes. For example, your class may wish to include further information with it's event, however every thing which used that event would break, as the delegate no longer matched. By having a strict delegate, your event can encapsulate more information in the future without affecting any subscribers.
Edit: As per the comments I'll expand on how this affects the reduction of breaking changes.
If we wished to add further information to our raised event, by using a single class derived from EventArgs new properties/methods can be added. This will mean any existing subscribers to the event will require no change, as the addition of these properties does not affect them. The only required change would be where these properties are set/used, e.g. where the event is raised.
The benefit is the pattern; and having a pattern gives both consistency and the the ability to use other APIs across multiple event types:
The EventHandler<T> delegate type (you don't need to define your own delegate type).
The Reactive Extensions (Rx) have conversion of an event into an IObservable<T> allowing use of LINQ on event sources with Observable.FromEvent.
Also you've got the signatures wrong:
The delegate takes two arguments: object source and SomethingEventArgs
The SomethingEventArgs type inherits EventArgs.
Thus your code should be, to be an exemplar of the pattern:
At namespace scope:
public class SomethingEventArgs : EventArgs {
public string Name;
public int Index;
public double Groar;
}
public delegate void SomethingSomething(object source, SomethingEventArgs e);
and in the type exposing the type
public event SomethingSomething OnSomethingSomething;
(An event could also be internal.)
As others have pointed out, there are maintainability and concistency reasons for this. The EventArgs approach also makes it possible for the event handler to modify the EventArgs.
One reason for modifying the EventArgs is errorhandling. An exception caught somewhere on a background thread is communicated to the client as an event. The client can set a flag in the EventArgs to indicate the exception was handled an shouldn't be rethrown on the background thread.
Another example is the ObjectDataSource class that lets the client supply an object instance when one is required. This is done by subscribing to the ObjectDataSource.ObjectCreating event and supplying the object instance by setting a member of the EventArgs.
Using a class allows the event's subscribers to effect the outcome.
When you pass an instance of a class as a parameter to a method, it is passed by reference. This allows the object instance to change during the method call. Those changed values can then be read by the caller after the event is raised.
For instance:
Look at the FormClosingEventHandler Delegate (in Windows Forms).
This delegate uses a parameter of type FormClosingEventArgs.
If a subscriber to an event using this delegate sets the Cancel property (inherited by CancelEventArgs) to true, then the form is not closed.
In addition, these answers are also correct:
jgauffin
Baszz
Firstly, the reason why this pattern is so common (as you have asked) is because Microsoft has specifically prescribed so when they developed the Event Pattern (yes they coined this term, too). I don't necessarily think this is better or worse than coming up with your own delegate signatures, but following a well-known convention can have its advantages.
Per Microsoft:
The return type is Void.
The first parameter is named sender and is of type Object. This is the object that raised the event.
The second parameter is named e and is of type EventArgs or a derived class of EventArgs. This is the event-specific data.
The method takes exactly two parameters.
To get more at the point of your question, though, I think the rationale for using EventArgs is twofold:
So that classes that inherit from your class can still raise the event, with a derived EventArgs class.
So that classes that handle your event can use common event handlers to handle several types of events, even if different events use different EventArgs. Or, if you change the event down the road, any classes that already handle the event don't need to change their code because the handlers will still be compatible with the new event.
For further reading, see more info from Microsoft:
More info about how to design events: http://msdn.microsoft.com/en-us/library/ms229011.aspx
A detailed how-to on using this pattern: http://msdn.microsoft.com/en-us/library/w369ty8x.aspx
In order to follow the .net standards, the recommanded way to create an event is:
Create a class that inherits from EventArgs
Use the EventHandler<T> generic delegate
As doing so reduces the amount of work required to subsequently change the number and types of values sent to event subscribers.
Example:
public event EventHandler<SometingEventArgs> SomethingEvent;
class SomethingEventArgs
{
public string Name;
public int Index;
public double Groar;
}
In addition to the backward-compatibility convention that others have already mentioned, the EventArgs class enables more control over how the parameters are contiguously accessed as they are passed to more than one object.
This control can be used to make certain values immutable, so that if an event is sent to 3 different subscribers you can guarantee it's not tampered with.
At the same time you can offer multiple [out] values, and you don't have to juggle return values or [ref] parameters, which significantly complicates the multicasting process. It also ensures that any validation logic occurs in the EventArgs subclass, NOT in the class that fires the events.
I have a utility class library I am writing. A have written a factory class that is generic enough that with a few delegates passed in from the caller it can be reused in many different situations. However, one of my colleagues suggested that I use an abstract class or an interface so it is more explicit what functions needed to be overridden. In the model I have created to use the library you would then need to override 2 classes instead of just one. What criteria determines when it is appropriate to use delegate functions or interfaces.
Using a delegate pattern.
Class A
{
Func<string , ReultClass> fun1 {get;set;}
FactoryObj CreateObj()
{
return fun1("")
}
}
Using an interface pattern
Class B
{
InterfaceObj{get;set;}
FactoryObj CreateObj()
{
return InterfaceObj.fun1("")
}
}
If the design is such that the class depends on another class (even a simple class), I would recommend the interface approach, since the object does have to depend on outside code:
interface IA
{
ResultClass Fun1(string arg);
}
In this case, you can still use delegates; I usually write my "anonymous" classes (as Microsoft calls them) with explicit interface implementations, so the name of the delegate property is the same as the name of the interface method it implements:
class AnonymousA : IA
{
Func<string, ResultClass> Fun1 { get; set; }
ResultClass IA.Fun1(string arg) { return this.Fun1(arg); }
}
If there are generics involved (e.g., IA<ResultClass> and the corresponding AnonymousA<ResultClass>), then it's useful to define a factory class, just to clean up the creation syntax:
static class Anonymous
{
public static IA<ResultClass> A<ResultClass>(Func<string, ResultClass> fun1)
{ return new AnonymousA<ResultClass> { Fun1 = fun1 }
}
I would think you would want to change the signature of the method. Instead of making the delegate a property on your class, make that a parameter you need to pass in. Then, you can't even invoke your CreateObj method without passing in the required data, and the signature itself tells you what you need to pass for the method call to be successful.
does/should the factory know about the various 'concrete' versions? Are there a fixed, relatively low number of specific concrete versions? If yes for either, IMHO the abstract base is a good approach. If the caller should be able to pass in 'arbitrary' code, you could either pass in delegates, or if multiple callers may want to handle/interpret the same data, expose it as events from the base and let the various callers hook up and do their interpretation.
Unfortunately, as SLaks mentions, it kind of depends on the specific situation - it's hard to make any kind of blanket statements - even the above one is likely to be a bad idea in some situations :)
Using wrapper classes, it's possible to do anything that can be done with delegates using interfaces, and vice versa. To determine which is appropriate for a given situation, examine the common usage patterns.
For example, suppose one wants to construct at run-time a list of actions that will need to be performed when a certain object is disposed. The most common action will be to call Dispose on an object of type IDisposable, but in some cases it may be necessary to do something else (e.g. unsubscribe an event handler).
One approach would be to maintain a list of MethodInvoker delegates and invoke each in turn(*). If cleanup will require calling Dispose on an object, make a new delegate for thatObject.Dispose() and add it to the list. An alternative approach would be to keep a list of IDisposable objects, and handle other actions by creating a class called InvokeOnDispose which holds a MethodInvoker, and invokes it when Dispose is called.
The former approach would require creating a new delegate for each cleanup action, whether it simply involved calling Dispose on something, or did something else. The latter approach would not require creating any new object instances when adding an IDisposable object to the list, but adding some other action would require creating an InvokeOnDispose object in addition to a delegate.
(*) One could simply use a MulticastDelegate rather than a list of delegates, but in some circumstances (like object cleanup) an exception thrown from one cleanup operation should probably not disrupt the operation of others. While one could assemble the collection of cleanup operations using a MulticastDelegate and then use GetInvocationList to run each within a separate 'try-catch' block, it would be easier and more efficient to simply use a list of delegates from the get-go.
I understand the purpose of events, especially within the context of creating user interfaces. I think this is the prototype for creating an event:
public void EventName(object sender, EventArgs e);
What do event handlers do, why are they needed, and how do I to create one?
To understand event handlers, you need to understand delegates. In C#, you can think of a delegate as a pointer (or a reference) to a method. This is useful because the pointer can be passed around as a value.
The central concept of a delegate is its signature, or shape. That is (1) the return type and (2) the input arguments. For example, if we create a delegate void MyDelegate(object sender, EventArgs e), it can only point to methods which return void, and take an object and EventArgs. Kind of like a square hole and a square peg. So we say these methods have the same signature, or shape, as the delegate.
So knowing how to create a reference to a method, let's think about the purpose of events: we want to cause some code to be executed when something happens elsewhere in the system - or "handle the event". To do this, we create specific methods for the code we want to be executed. The glue between the event and the methods to be executed are the delegates. The event must internally store a "list" of pointers to the methods to call when the event is raised.* Of course, to be able to call a method, we need to know what arguments to pass to it! We use the delegate as the "contract" between the event and all the specific methods that will be called.
So the default EventHandler (and many like it) represents a specific shape of method (again, void/object-EventArgs). When you declare an event, you are saying which shape of method (EventHandler) that event will invoke, by specifying a delegate:
//This delegate can be used to point to methods
//which return void and take a string.
public delegate void MyEventHandler(string foo);
//This event can cause any method which conforms
//to MyEventHandler to be called.
public event MyEventHandler SomethingHappened;
//Here is some code I want to be executed
//when SomethingHappened fires.
void HandleSomethingHappened(string foo)
{
//Do some stuff
}
//I am creating a delegate (pointer) to HandleSomethingHappened
//and adding it to SomethingHappened's list of "Event Handlers".
myObj.SomethingHappened += new MyEventHandler(HandleSomethingHappened);
//To raise the event within a method.
SomethingHappened("bar");
(*This is the key to events in .NET and peels away the "magic" - an event is really, under the covers, just a list of methods of the same "shape". The list is stored where the event lives. When the event is "raised", it's really just "go through this list of methods and call each one, using these values as the parameters". Assigning an event handler is just a prettier, easier way of adding your method to this list of methods to be called).
C# knows two terms, delegate and event. Let's start with the first one.
Delegate
A delegate is a reference to a method. Just like you can create a reference to an instance:
MyClass instance = myFactory.GetInstance();
You can use a delegate to create an reference to a method:
Action myMethod = myFactory.GetInstance;
Now that you have this reference to a method, you can call the method via the reference:
MyClass instance = myMethod();
But why would you? You can also just call myFactory.GetInstance() directly. In this case you can. However, there are many cases to think about where you don't want the rest of the application to have knowledge of myFactory or to call myFactory.GetInstance() directly.
An obvious one is if you want to be able to replace myFactory.GetInstance() into myOfflineFakeFactory.GetInstance() from one central place (aka factory method pattern).
Factory method pattern
So, if you have a TheOtherClass class and it needs to use the myFactory.GetInstance(), this is how the code will look like without delegates (you'll need to let TheOtherClass know about the type of your myFactory):
TheOtherClass toc;
//...
toc.SetFactory(myFactory);
class TheOtherClass
{
public void SetFactory(MyFactory factory)
{
// set here
}
}
If you'd use delegates, you don't have to expose the type of my factory:
TheOtherClass toc;
//...
Action factoryMethod = myFactory.GetInstance;
toc.SetFactoryMethod(factoryMethod);
class TheOtherClass
{
public void SetFactoryMethod(Action factoryMethod)
{
// set here
}
}
Thus, you can give a delegate to some other class to use, without exposing your type to them. The only thing you're exposing is the signature of your method (how many parameters you have and such).
"Signature of my method", where did I hear that before? O yes, interfaces!!! interfaces describe the signature of a whole class. Think of delegates as describing the signature of only one method!
Another large difference between an interface and a delegate is that when you're writing your class, you don't have to say to C# "this method implements that type of delegate". With interfaces, you do need to say "this class implements that type of an interface".
Further, a delegate reference can (with some restrictions, see below) reference multiple methods (called MulticastDelegate). This means that when you call the delegate, multiple explicitly-attached methods will be executed. An object reference can always only reference to one object.
The restrictions for a MulticastDelegate are that the (method/delegate) signature should not have any return value (void) and the keywords out and ref is not used in the signature. Obviously, you can't call two methods that return a number and expect them to return the same number. Once the signature complies, the delegate is automatically a MulticastDelegate.
Event
Events are just properties (like the get;set; properties to instance fields) which expose subscription to the delegate from other objects. These properties, however, don't support get;set;. Instead, they support add; remove;
So you can have:
Action myField;
public event Action MyProperty
{
add { myField += value; }
remove { myField -= value; }
}
Usage in UI (WinForms,WPF,UWP So on)
So, now we know that a delegate is a reference to a method and that we can have an event to let the world know that they can give us their methods to be referenced from our delegate, and we are a UI button, then: we can ask anyone who is interested in whether I was clicked, to register their method with us (via the event we exposed). We can use all those methods that were given to us and reference them by our delegate. And then, we'll wait and wait.... until a user comes and clicks on that button, then we'll have enough reason to invoke the delegate. And because the delegate references all those methods given to us, all those methods will be invoked. We don't know what those methods do, nor we know which class implements those methods. All we do care about is that someone was interested in us being clicked, and gave us a reference to a method that complied with our desired signature.
Java
Languages like Java don't have delegates. They use interfaces instead. The way they do that is to ask anyone who is interested in 'us being clicked', to implement a certain interface (with a certain method we can call), then give us the whole instance that implements the interface. We keep a list of all objects implementing this interface and can call their 'certain method we can call' whenever we get clicked.
That is actually the declaration for an event handler - a method that will get called when an event is fired. To create an event, you'd write something like this:
public class Foo
{
public event EventHandler MyEvent;
}
And then you can subscribe to the event like this:
Foo foo = new Foo();
foo.MyEvent += new EventHandler(this.OnMyEvent);
With OnMyEvent() defined like this:
private void OnMyEvent(object sender, EventArgs e)
{
MessageBox.Show("MyEvent fired!");
}
Whenever Foo fires off MyEvent, then your OnMyEvent handler will be called.
You don't always have to use an instance of EventArgs as the second parameter. If you want to include additional information, you can use a class derived from EventArgs (EventArgs is the base by convention). For example, if you look at some of the events defined on Control in WinForms, or FrameworkElement in WPF, you can see examples of events that pass additional information to the event handlers.
Here is a code example which may help:
using System;
using System.Collections.Generic;
using System.Text;
namespace Event_Example
{
// First we have to define a delegate that acts as a signature for the
// function that is ultimately called when the event is triggered.
// You will notice that the second parameter is of MyEventArgs type.
// This object will contain information about the triggered event.
public delegate void MyEventHandler(object source, MyEventArgs e);
// This is a class which describes the event to the class that receives it.
// An EventArgs class must always derive from System.EventArgs.
public class MyEventArgs : EventArgs
{
private string EventInfo;
public MyEventArgs(string Text) {
EventInfo = Text;
}
public string GetInfo() {
return EventInfo;
}
}
// This next class is the one which contains an event and triggers it
// once an action is performed. For example, lets trigger this event
// once a variable is incremented over a particular value. Notice the
// event uses the MyEventHandler delegate to create a signature
// for the called function.
public class MyClass
{
public event MyEventHandler OnMaximum;
private int i;
private int Maximum = 10;
public int MyValue
{
get { return i; }
set
{
if(value <= Maximum) {
i = value;
}
else
{
// To make sure we only trigger the event if a handler is present
// we check the event to make sure it's not null.
if(OnMaximum != null) {
OnMaximum(this, new MyEventArgs("You've entered " +
value.ToString() +
", but the maximum is " +
Maximum.ToString()));
}
}
}
}
}
class Program
{
// This is the actual method that will be assigned to the event handler
// within the above class. This is where we perform an action once the
// event has been triggered.
static void MaximumReached(object source, MyEventArgs e) {
Console.WriteLine(e.GetInfo());
}
static void Main(string[] args) {
// Now lets test the event contained in the above class.
MyClass MyObject = new MyClass();
MyObject.OnMaximum += new MyEventHandler(MaximumReached);
for(int x = 0; x <= 15; x++) {
MyObject.MyValue = x;
}
Console.ReadLine();
}
}
}
Just to add to the existing great answers here - building on the code in the accepted one, which uses a delegate void MyEventHandler(string foo)...
Because the compiler knows the delegate type of the SomethingHappened event, this:
myObj.SomethingHappened += HandleSomethingHappened;
Is totally equivalent to:
myObj.SomethingHappened += new MyEventHandler(HandleSomethingHappened);
And handlers can also be unregistered with -= like this:
// -= removes the handler from the event's list of "listeners":
myObj.SomethingHappened -= HandleSomethingHappened;
For completeness' sake, raising the event can be done like this, only in the class that owns the event:
//Firing the event is done by simply providing the arguments to the event:
var handler = SomethingHappened; // thread-local copy of the event
if (handler != null) // the event is null if there are no listeners!
{
handler("Hi there!");
}
The thread-local copy of the handler is needed to make sure the invocation is thread-safe - otherwise a thread could go and unregister the last handler for the event immediately after we checked if it was null, and we would have a "fun" NullReferenceException there.
C# 6 introduced a nice short hand for this pattern. It uses the null propagation operator.
SomethingHappened?.Invoke("Hi there!");
My understanding of the events is;
Delegate:
A variable to hold reference to method / methods to be executed. This makes it possible to pass around methods like a variable.
Steps for creating and calling the event:
The event is an instance of a delegate
Since an event is an instance of a delegate, then we have to first define the delegate.
Assign the method / methods to be executed when the event is fired (Calling the delegate)
Fire the event (Call the delegate)
Example:
using System;
namespace test{
class MyTestApp{
//The Event Handler declaration
public delegate void EventHandler();
//The Event declaration
public event EventHandler MyHandler;
//The method to call
public void Hello(){
Console.WriteLine("Hello World of events!");
}
public static void Main(){
MyTestApp TestApp = new MyTestApp();
//Assign the method to be called when the event is fired
TestApp.MyHandler = new EventHandler(TestApp.Hello);
//Firing the event
if (TestApp.MyHandler != null){
TestApp.MyHandler();
}
}
}
}
//This delegate can be used to point to methods
//which return void and take a string.
public delegate void MyDelegate(string foo);
//This event can cause any method which conforms
//to MyEventHandler to be called.
public event MyDelegate MyEvent;
//Here is some code I want to be executed
//when SomethingHappened fires.
void MyEventHandler(string foo)
{
//Do some stuff
}
//I am creating a delegate (pointer) to HandleSomethingHappened
//and adding it to SomethingHappened's list of "Event Handlers".
myObj.MyEvent += new MyDelegate (MyEventHandler);
publisher: where the events happen. Publisher should specify which delegate the class is using and generate necessary arguments, pass those arguments and itself to the delegate.
subscriber: where the response happen. Subscriber should specify methods to respond to events. These methods should take the same type of arguments as the delegate. Subscriber then add this method to publisher's delegate.
Therefore, when the event happen in publisher, delegate will receive some event arguments (data, etc), but publisher has no idea what will happen with all these data. Subscribers can create methods in their own class to respond to events in publisher's class, so that subscribers can respond to publisher's events.
I recently made an example of how to use events in c#, and posted it on my blog. I tried to make it as clear as possible, with a very simple example. In case it might help anyone, here it is: http://www.konsfik.com/using-events-in-csharp/
It includes description and source code (with lots of comments), and it mainly focuses on a proper (template - like) usage of events and event handlers.
Some key points are:
Events are like "sub - types of delegates", only more constrained (in a good way). In fact an event's declaration always includes a delegate (EventHandlers are a type of delegate).
Event Handlers are specific types of delegates (you may think of them as a template), which force the user to create events which have a specific "signature". The signature is of the format: (object sender, EventArgs eventarguments).
You may create your own sub-class of EventArgs, in order to include any type of information the event needs to convey. It is not necessary to use EventHandlers when using events. You may completely skip them and use your own kind of delegate in their place.
One key difference between using events and delegates, is that events can only be invoked from within the class that they were declared in, even though they may be declared as public. This is a very important distinction, because it allows your events to be exposed so that they are "connected" to external methods, while at the same time they are protected from "external misuse".
Another thing to know about, in some cases, you have to use the Delegates/Events when you need a low level of coupling !
If you want to use a component in several place in application, you need to make a component with low level of coupling and the specific unconcerned LOGIC must be delegated OUTSIDE of your component ! This ensures that you have a decoupled system and a cleaner code.
In SOLID principle this is the "D", (Dependency inversion principle).
Also known as "IoC", Inversion of control.
You can make "IoC" with Events, Delegates and DI (Dependency Injection).
It's easy to access a method in a child class. But more difficult to access a method in a parent class from child. You have to pass the parent reference to the child ! (or use DI with Interface)
Delegates/Events allows us to communicate from the child to the parent without reference !
In this diagram above, I do not use Delegate/Event and the parent component B has to have a reference of the parent component A to execute the unconcerned business logic in method of A. (high level of coupling)
With this approach, I would have to put all the references of all components that use component B ! :(
In this diagram above, I use Delegate/Event and the component B doesn't have to known A. (low level of coupling)
And you can use your component B anywhere in your application !
I agree with KE50 except that I view the 'event' keyword as an alias for 'ActionCollection' since the event holds a collection of actions to be performed (ie. the delegate).
using System;
namespace test{
class MyTestApp{
//The Event Handler declaration
public delegate void EventAction();
//The Event Action Collection
//Equivalent to
// public List<EventAction> EventActions=new List<EventAction>();
//
public event EventAction EventActions;
//An Action
public void Hello(){
Console.WriteLine("Hello World of events!");
}
//Another Action
public void Goodbye(){
Console.WriteLine("Goodbye Cruel World of events!");
}
public static void Main(){
MyTestApp TestApp = new MyTestApp();
//Add actions to the collection
TestApp.EventActions += TestApp.Hello;
TestApp.EventActions += TestApp.Goodbye;
//Invoke all event actions
if (TestApp.EventActions!= null){
//this peculiar syntax hides the invoke
TestApp.EventActions();
//using the 'ActionCollection' idea:
// foreach(EventAction action in TestApp.EventActions)
// action.Invoke();
}
}
}
}
Great technical answers in the post! I have nothing technically to add to that.
One of the main reasons why new features appear in languages and software in general is marketing or company politics! :-) This must not be under estimated!
I think this applies to certain extend to delegates and events too! i find them useful and add value to the C# language, but on the other hand the Java language decided not to use them! they decided that whatever you are solving with delegates you can already solve with existing features of the language i.e. interfaces e.g.
Now around 2001 Microsoft released the .NET framework and the C# language as a competitor solution to Java, so it was good to have NEW FEATURES that Java doesn't have.
DELEGATES, EVENTS(EVENT HANDLERS/EVENT LISTENERS), CONCEPTS(MULTICASTING/BROADCASTING), ACTION & FUNC
This will be a long one but its the simplest explanation, the problem this is such a nuisance of a topic is because people are just using different words to explain the same thing
First of all, you should know a few things
DELEGATES: It's nothing but a list of methods, why create a list? because when your code is being executed, that list is taken and every method there is executed one by one, just don't listen to textbook definitions take this and you will be all right
also called :
a pointer to a function
a wrapper for a method that can send and receive methods just like a variable
to create a delegate you go
[[access modifier] delegate [return type] [delegate name]([parameters])]
example: public delegate int demo(int a);
now to execute all these methods stored in a list called delegate, you go
1. demo.invoke(a);
2. demo(a); ..... both are valid
using the dot and explicitly saying invoke shines in async programming where you use beginInvoke, but that is out of the scope of this topic
there is one more thing called "Creating an object of the delegate/instantiate Delegate" which is pretty much as it sounds but just to avoid confusion it goes like (for the above example )
example : demo del = new demo(); (or) Public demo del = null;
to add any method to the list called delegate you go += and you also need to remove it once the "requirements of the methods are met" you go -=
(requirements of the methods are met mean you no longer need the method to be active or aka "listening") if you don't remove it, it could cause a "memory leak" meaning your computers ram will be eaten alive, technically allocated memory will not be released
example: say there is a method
public int calculate (int c)
to add this method to delegate you go
1. del = calculate;
2. del += calculate; .... all are valid
to remove
del -= calculate
first of all notice the similarities between the delegate and the method, the return type(output) and the input/parameters are the same, and that is a rule you just cannot add any random or a bunch of methods in a delegate it needs to follow the input-output rule
now why are there 2 different ways to do one thing, the only thing different is the assignment operators (+, =), this introduces a new topic called
EVENTS
which is nothing but a constrained version of a Delegate, It's still a List of methods don't confuse when people explain these terminologies, they change the name, so stick with this to understand
what is the constraint? you cannot do this del = calculate;
what's the harm in it, say a bunch of methods are added to the Delegate(List), you do that 👆 all are wiped out and only a single method "calculate" remains, so to prevent that Events are used,
Event Syntax
Public Event demo del = null;
One more thing you cannot do with events is invoke the delegate directly like demo.invoke since its public it can be accessed and invoked but with events, it can't
now you just add the methods to the event (a special type of delegate)
when to use an event vs a delegate, depends on your situation but pragmatically events are popular
few more keywords
MULTICASTING: nothing but adding more than one method to a delegate
BROADCASTING: adding more than one method to an event
PUBLISHER: the one that executes the method (term used in broadcasting), only a single entity
SUBSCRIBER: The methods that are being executed, can be multiple
LISTENER: the same thing as a subscriber but the term is used in multicasting
EVENT HANDLER: same thing as a subscriber/event listener so what the difference? it's basically the same thing, some say an eventlistener detect for the event to occur and the event handler "handles" or execute the code, ITS THE SAME THING PRACTICALLY!
action and func are just delegates that have been created and instantiated so 2 lines of code in a word, the difference is just in return types
ACTION: does not return anything while taking 0 or more than 1 input
FUNC: returns one thing and takes in parameters
if you don't do good with reading here is the best video on this topic
https://www.youtube.com/playlist?list=PLFt_AvWsXl0dliMtpZC8Qd_ru26785Ih_