CODEWITHSUNDEEP
c#eventsmethods
Wil
Wil

Reputation: 10604

How to decide between a method or event?

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?

Upvotes: 1

Views: 322

Answers (4)

Shiv Kumar
Shiv Kumar

Reputation: 9799

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.

Upvotes: 0

Andre Hühn
Andre Hühn

Reputation: 37

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. :)

Upvotes: 0

0x49D1
0x49D1

Reputation: 8704

To gain more information about events see this post.

Upvotes: 1

BinaryTox1n
BinaryTox1n

Reputation: 3556

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.

Upvotes: 0

Related Questions