|
||||||||||||||
|
MYBLOG
"The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. - Frederick P. Brooks
 |
|
From Delegates to Events erstellt am 10.04.2009 A couple weeks ago I held a workshop at my university in Heilbronn. Some people ask me why the C# programming language uses an extra keyword for events. During some discussions I tried to figure out why they had such a problem in that. What I recognized, was that they saw an event as a kind of a restricted delegate. In this article I will clarify the responsibilities of delegates and events. Additionally, I will emphasize the sense of such ‘restricted delegates’ by using the view of a software-engineer. The C# language specification specifies a delegate similar as function pointers in some other languages. A great advantage of delegates is that they are type-safe and object-oriented. Figure 1 emphasizes the common principle of a delegate.
As you can see on the picture, there is a delegate declared within the scope of a namespace. This declaration is used by the notifier object to determine the signature of the handler method. The notify delegate holds a handle to the method to invoke and the notify method is used to invoke this method. Unlike a delegate, an event has to be declared as a member of an object enabling it to provide notifications to other objects. In this context a method invoked by an event is called event handler. The following picture shows the concept of events.
If you compare the first two pictures you will probably recognize the missing delegate declaration in figure 2. That is why the framework already has a standard delegate declaration for events. The following line shows the delegate type of an event. public delegate void EventHandler(object sender, EventArgs e); For a better illustration, I use a delegate without parameters in the code samples of this article. public delegate void MyDelegateDeclaration(); Apart from that, the handler and notifier objects have just renamed members. This model is now a bit more simplified for its purpose of notifying other objects and uses the event system of the language. Therefore events are a kind of delegates, but what makes the difference? Events encapsulate delegates and restrict them in some ways. They can only be declared within objects and the operations that are permitted on an event by code that is outside the type in which that event is declared, are += and -=. Therefore, while such code can add and remove handlers for an event, it cannot directly obtain or modify the underlying list of event handlers. In short, the difference is the behavior. Events are declared for notifying other objects; neither more, nor less. This scenario of the publish-subscribe-pattern is supported by the language itself making it trivial to get callbacks from other objects. A subscriber can register for an event and the publisher sends notifications back when events are fired. To emphasize these differences I will show you the mapping of the above models in code.
In figure 3 you will see the delegate declaration “MyDelegateDeclaration”. Instead of using an own delegate declaration I use in figure 4 the built in type “EventHandler” as said above.
If you compare these two code snippets you should recognize, that by using events directly you can concentrate on your publish subscribe scenario and do not need the overhead of encapsulating delegates, implementing add and remove functionalities yourself. Furthermore if everyone has to implement this pattern you would probably have no standard object notification mechanisms.
|
||||||||||||
|
|
||||||
|
 |
|||
|
|||
|
|||
|
|||
|
|||||||
|
|||||||