I'm using custom Events in Actionscript 3.0 for the first time and I'm unsure about how to best design them. I need a couple of Events. Some of them need to transport different kinds of data and some don't. Now I don't know whether I should use a single class to implement them all or use separate classes for different kinds of purposes. Creating an own event class for every kind of data seems a bit messy to me since these events would basically all still do the same thing. But I don't really like the option with a single class that much either. This class would need a generic variable to store any kind of data which would also be unused a lot of the times. Also, I would have to typecast all the data I want to access from it. And what if there are sometimes multiple objects to be transported? Which one is the way to go (style wise) or is there another way I haven't thought of?
views:
209answers:
4Custom Actionscript 3.0 Events: Build separate Classes for different purposes or use one for all?
I think it depends on the context. Cairngorm's general best practices are to severely limit the purposes of new Events. I've often seen a one-to-one mapping of Event Types to Event Classes to Commands. This is nothing if not explicit.
On the other hand the FlexEvent has quite as variety of different uses, and that is (technically) a custom event. That makes perfect sence in its context -- it is generally functioning as a parallel to the rendering events of the DisplayObject...
If you're just talking about a new event TYPE (and no extra data needs to be carried) do not re-invent the wheel -- Event takes type as a parameter. Store the new type in some public static constant, and then use that.
If you do need to have data carried, my general recommendation is to err or the side of strongly-typed variables wherever possible, this way you'll have the benefit of compile-time errors. If this can be made more generic (say, IList instead of ArrayCollection), that is better, but, barring that, the more explicit that you make your code the easier.
Really it depends on, like most other code, how easy is it to understand whats going on. If its easier with one class, use one, if its easier with more use case specific classes, use more.
Actionscript wise, youll save a few bytes on having just one class but the programing best-practice is always what is best for code reuse and easiest for code understanding.
You can also put as many type specific public properties on your custom event as you like and only assign or retrieve from the one you need instead of having one generic data property.
I suspect that finding the right balance becomes a tightrope walk and that a lot of this is personal preference, but I've always felt that it's better to have more events than fewer for a couple of reasons:
1) Code Optimization - if you just need to send a string, don't pass it in an object - that creates more complexity than you need. Likewise, if your data payload has to be huge and complex, a single object may not be enough. Creating different event types based on your data payload is, I think, a bare minimum.
2) Code Readability - yes it gets complex in something like Cairngorm with a billion events, but you know what? I always know exactly what event does, and there's never any question about where it's coming from. If you're working on a large enough project that A) other people will read your code or B) you may forget over time what each event does, then I'd definitely suggest breaking all the events into custom classes.
Hope that helps!