13

I'm new to programming and I've been checking a lot of game coding tutorials. I've noticed that on most of them they use custom events to trigger methods instead of calling a method directly.

What's the reasoning behind this practice? Why aren't they just calling the method?

For example:

We have two objects: A and B. A has method A.methodA() that B needs to use when X condition is triggered.

Why implement:

B dispatches an event to A that tells A to run A.methodA()

Instead of:

B uses A.methodA()

BadFeelingAboutThis
  • 14,445
  • 2
  • 33
  • 40
NPN328
  • 1,863
  • 3
  • 27
  • 47
  • well, making a reference every time u need to trigger a method, u're making life easier for the garbage collector =) (he will have less things to worry about). – Ziul Nov 27 '12 at 18:19

5 Answers5

15

The main reason is separation of interests. When using events, class A doesn't need to know about the existence of class B (and vice versa).

Some benefits to this are:

  • Much easier unit testing (you can test Class A without class B)
  • Less chance of breaking your code when you change class A or B
  • Less references to other classes in your code, which reduces the potential for memory leaks
  • Cleaner code
  • More flexible/reusable code (a bunch of other classes could all listen/respond to the event without any additional code in the your dispatcher)
BadFeelingAboutThis
  • 14,445
  • 2
  • 33
  • 40
  • 5
    +1; I would also add that events are the proper way for an object to communicate with its parent. Method calls or public properties are the proper way that a parent should communicate with its children. – JeffryHouser Nov 27 '12 at 19:54
  • 3
    @www.Flextras.com - agreed, especially if children classes are used with varying parent classes. – BadFeelingAboutThis Nov 27 '12 at 20:42
4

Typically in bigger applications using events will help abstract everything. When you have 15+ classes and they're all ditpatching events to a controller, it's a lot easier to figure out what's going on than reading through all different parts of the code to trace functions. Using callbacks begins to create spaghetti code.

However, direct function calls are going to be executed faster than events.

lostPixels
  • 1,303
  • 9
  • 23
2

Personally, I use custom events simply for the ease of use. I can have one class dispatch an event when something happens (say an animation finishes or an error occurs in a download) and any number of other classes run any number of other functions based on that event. In addition, I code for reusability. The goal of each class is complete independence so that it can run in any project without needing other packages. So rather than have one class call a method of another class, I dispatch an event from the first class that the second class listens for and then run that method. Then when I need that first class for another project, I can just copy/paste it without having to modify it and without losing any functionality.

EDIT: Also, it's worth noting that sometimes people do what you describe to get around having to pass in event arguments.

Say you have a button on the stage and you need to be able to click it, but you also need to be able to manually call that method. Some people don't realize you can pass in a null event and have only the single method. Or you can set it as a null default argument, see below:

private function onClickHandler( e:MouseEvent = null ):void{
    //as long as you never reference "e" within this method, this method can be used both for MouseEvent listeners and manually calling it elsewhere in the code
}

That technique can help avoid having an event handler that only calls another method and nothing else. At this point in my programming, every single AS3 event handler I write sets the event argument to null by default. It just makes things easier later on.

Josh
  • 8,079
  • 3
  • 24
  • 49
1

You might want to read this.

And also note using the callback method allows you to pass parameters to it directly and not via a custom event model.

The_asMan
  • 6,364
  • 4
  • 23
  • 34
1

I built my own, very simplified, events dispatcher system. AS Event model is very powerful, but in 99% of situations you don't need that power. A simple callback with parameters fired as an event is more than enough. You can still retain the versatility from an event model, but don't need to write too many lines of code for, let's say, a simple button. I can setup a simple event like this:

Buttonizer.autoButton(_buttQuit, this, "onPress");
public function onPressQuit(c:Sprite) {
// Execution goes here
}

You can build your own event model, it will make life simpler, and your code much more concise.

FilippoG
  • 546
  • 3
  • 16