2

Possible Duplicate:
What is the difference between a delegate and events?

I couldn't understand the difference between delegate and event

Community
  • 1
  • 1
lital maatuk
  • 5,921
  • 20
  • 57
  • 79

4 Answers4

12

Suppose your business has a customer, Petunia Dursley. Petunia is female and lives at #4 Privet Drive.

You might want to represent your customers with an object in your computer system, so you make a Customer class that has properties like "Name" and "Address" and "Sex". Perhaps Name and Address are both strings, perhaps "Sex" is an enum.

Now, is Petunia's address a string? Of course not. It's an address. It is represented by an object of type String in your model. Because Petunia the person has properties like name, address and sex, the corresponding object in your system also has properties Name, Address and Sex.

A property in the class is a model of a property of a thing in the business domain, such as a property of customer. The choice of the mechanisms that implement that property is based on what is most convenient for the people building and using the software model. In this case, probably the mechanism is a bunch of fields of various types such that the properties contain code that accesses the field. Those are mechanisms that implement the properties.

Events and delegates have the same relationship. An "event" is a software representation of "something that happens that you'd like to be informed about". A delegate is the mechanism that implements the event.

A button can be clicked; that's a fact about buttons. That fact is modeled in software by a "Click" event. When the button is clicked, the mechanism that informs interested parties that the click event has occurred is a delegate.

Summing up: Events and properties are used to represent concepts in the business domain of the type. Fields are (usually) the mechanism that properties use to do their work, and delegates are (always) the mechanism that events use to do their work.

Is that clear?

Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
5

Here's a really good explanation by Jon Skeet: http://csharpindepth.com/Articles/Chapter2/Events.aspx

Jackson Pope
  • 14,520
  • 6
  • 56
  • 80
2

An event is an accessor for a delegate. Just like a property is an accessor for a field. A property has the get and set accessors, an event has the add, remove and raise accessors. Unlike a property, you don't have to explicitly write these accessors, the compiler generates a default implementation for them. Which is often good enough.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Events don't have "raise" accessors. Just add and remove. The only entity which would generally be allowed to raise an event is the entity which defines the "add" and "remove" accessors; it is thus assumed that such an event will know what to do to raise its own event. – supercat Feb 22 '11 at 18:54
1

Conceptually, a delegate is a reference to a method on an instance of an object, allowing it to be severed from the object itself and passed around in code without knowledge of its containing instance.

An event is a built-in implementation of the "observer" pattern, in which "listening" objects are told by the "broadcast" object that something they were waiting to have happen has happened. In .NET, a special delegate that supports holding multiple method references (a MultiCastDelegate) is used to implement this. It's not the only way it can be done; events could use a polling mechanism (a "pull" method) instead of delegates (a "push" mentality).

So, the delegate is the basic building block on which a tool like an event is built. Events are one use of delegates; other common uses include callbacks (used widely in asynchronous design patterns) and lambda statements (implemented in .NET as anonymous delegates).

KeithS
  • 70,210
  • 21
  • 112
  • 164