1

I read a question ages ago "How do C# Events work behind the scenes?" and Jon answered that all events are similar to methods...

In a purely hypothetical situation, I was wondering if someone could explain or point me to a resource that says when to use an event over a method?

Basically, If I want to have a big red/green status picture which is linked to a Bool field, and I wanted to change it based on the value of the bool, should I:

a) Have a method called Changepicture which is linked to the field and changes the state of the bool and the picture.

b) Have a get/set part to the field and stick an event in the set part.

c) Have a get/set part to the field and stick a method in the set part.

d) Other?

Community
  • 1
  • 1
Wil
  • 10,234
  • 12
  • 54
  • 81
  • maybe a look at msdn (http://msdn.microsoft.com/en-us/library/17sde2xt%28v=VS.85%29.aspx) could clarify the usage of events/delegates. In contrast to methods there are posibly more than one class to receive the "event". – ralf.w. Feb 24 '11 at 07:09
  • is this a question or are you looking for some skeet loving? ;) – kenny Feb 24 '11 at 07:11
  • @kenny ehh, theres no way not to make that sound terribly inappropriate... – BinaryTox1n Feb 24 '11 at 07:14
  • How do you "stick an event in the set part"? I'm not really sure what you're asking here. You call a method yourself explicitly; events are raised by external code, which you can choose to handle locally if you so choose. – Cody Gray - on strike Feb 24 '11 at 07:22
  • @kenny - huh? :S It is as it reads! I have a bool representing if an xml request has been sent or not... I ideally want a toolbar that shows the status and I don't know the best way to update it upon an api request... event or method! I was trying not to get in to specifics or everyone would be asking for code samples which I haven't started to write yet! I just remember reading Jon wrote about IL in an article I was linked to about them being similar, and wanted some advice! – Wil Feb 24 '11 at 07:22
  • I would recommend reading the section on events in 'CLR via C#' by Jeffrey Richter – Adam Ralph Feb 24 '11 at 07:37
  • 2
    @Wil, similar or not, your design shouldn't have to rely/depend on how they are implemented in IL or any form for that matter. They serve very different purposes and mean different things to those using your classes (including yourself). In your case (without know details) since you're working in a GUI I'd say raise an event (RequestSent). That way if tomorrow other UI elements needs to reflect or change state based on this "event" then they can simply subscribe to the event without any coupling between each other, request calling code or the object making the request. – Shiv Kumar Feb 24 '11 at 09:20
  • @Shiv Kumar - I am not that bothered about how in IL they are done, but that is the sort of answer I really want... when should I use one over the other, what are the benefits etc.... Now trying to read through all the answers. – Wil Feb 24 '11 at 16:14

4 Answers4

1

To gain more information about events see this post.

0x49D1
  • 8,505
  • 11
  • 76
  • 127
0

You have options.

If your object already implements INotifyPropertyChanged and your red/green picture is a control which supports databinding, then you can simply fire the NotifyPropertyCHanged event on the bool's set method, and add a databinding on that property to your control.

If not implementing INotifyPropertyChanged, I would still recommend doing something similar. I.e. creating your own event handler, and having the reg/green picture subscribe to the event. Just straight up calling a method from the set of your property creates a tight coupling, which is generally a bad thing to do.

BinaryTox1n
  • 3,486
  • 1
  • 36
  • 44
0

The answer is: It depends. If your boolean value is in the codebehind class of your visual component (e.g. WinForm) you can call a method ChangePicture without doing strange things. But if your boolean value is architectural more far away from the visual component an event is the right way to handle the scenario because you can not easily call a method on the visual component because the class that contains the boolean value perhaps doesn´t even know your visual component exists. :)

Andre Hühn
  • 37
  • 2
0

The best way to figure out what you should do is to look at classes in the .NET framework and see how they are designed.

Methods are "doers" or "actions", while you can see events as notification mechanisms. That is if others could be interested is being notified when something happens in an object then you can surface an event and have one or more subscribers to these events.

Since events in .NET are multi-cast, meaning multiple objects can subscribe and therefore be notified of an event happening, that may be other reason to raise an event in your objects. Events also follow the observer pattern in that the subject (your class) is really unaware of the subscribers (loosely coupled). While in order to call a method, the secondary object needs to have a reference to an instance of your class.

Note that, a method in your class eventually raises and event. So let's say you have a method in your class called ChangePicture. Then in the method's implementation, you could eventually raise an event PictureChanged. if someone is interested in being notified of this event, they can subscribe to this event. This someone is typically not the one that made the method call to change the picture.

Events are delegates. Delegates are objects. Event's are actually MulticastDelegates (a base class in the .NET framework). These objects eventually call a method, which is the method that gets called as part of the event notification. So they are slightly "heavier" then just a method call, but that should almost never determine your design.

Shiv Kumar
  • 9,599
  • 2
  • 36
  • 38