Why create events in C#?

Question

Why would I go to the effort of creating my own events. Surely if I want an objects method to run I can just call it. Instead I have to trigger a custom event and have my class subscribe to the event. I'm sure there's a valid reason but I don't think I'm understanding it right.

Answer 1

You *could* hard-code all your method calls into your code, but that seriously decreases the level of abstraction and reusability within your code. Also with an event-driven structure classes can subscribe or unsubscribe to events at run-time; with a hard-coded structure they cannot.



For example in an Observer structure (one or more classes register their interest in an event from a class; when the event is triggered it broadcasts a notification to all observers) all the class being observed needs to know about its observers is that they implement an interface that declares a notify() method allowing them to be informed of the event. The individual classes can then choose whether or not they need to act on the event. As an example, if 4 classes are observing a class that triggers an event when a numerical value changed, observer A might be interested no matter what the change, observer B might only be interested if the number is negative, observer C might only be interested if the number has went over 100, etc. Hard-coding that into your observed class is wasteful - what if it had 100 observers? What if the criteria for some classes are constantly changing? Also if observer A suddenly decided it wasn't interested in recieving broadcasts any more it could simply unsubscribe; that isn't possible in a hard-coded structure.



By keeping the connection between classes abstract, ie the class being observed simply broadcasts and knows nothing about the underlying conditions for action in each class, it greatly decouples your code and increases resuability. It also makes it easier to add or remove as many observers as you want and allows them to perform whatever actions they need without holding up your main thread.

Answer 2

A typical problem that events can solve (in any language) is how to provide feedback to your clients (the UI) while continuing with a complex process (that could not be interrupted). For instance if you had a function that did the following; check for a new file on a server, download it, open it, read the contents, validate each line and then add to a database. You would need to inform the user interface of the functions progress (as each line was processed), so it could display a progress bar to the user. You could raise an event (subscribed to by the client) for each line in the file. The client (subscriber) then would move the progress bar forward each time the event was raised.



Without events the alternative would be to drive the process from the user interface, which would reduce the portability of the code, as it couldn't be packaged into a dll and reused by another system because it would be bound to the user interface of the original system.



This is a classical use of events in a desktop environment.

Answer 3

Sure, you can just call the method, but what if you want to be able to add and remove components to the event? Then you have to modify ALL your code. If you use events, you just have to register the new component.