On 5/19/15, 10:33 AM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote: >>And then, unlike Starling and current Flex which has dozens of constants >> declared on the Event class, I want to experiment with putting those >> constants on the class that dispatches the event. Having every constant >> on Event doesn’t scale well. When you get to 100’s of constants you >>could >> be bringing in lots of strings that aren’t used and the documentation >>gets >> unwieldy. Third-parties can’t be changing the Event class for their >> components so instead of creating subclasses of Event, why not just >> declare the constant on the same class that is dispatching it? > > >The problem with declaring the constant on the same class that is >dispatching it is that it would create an unnecessary compile time >dependency between the class that is dispatching the event and the class >that is listening to it. I think having classes loosely coupled via >events is a good thing. Is it bad OO practise? I think that is >debatable. But, this is truly where the power of event driven applications >lies in. > >I usually organize my shared components in a library project, then create >one or multiple app projects that compose these components as needed. > >I could have two different view component dispatch a 'dateRangeChanged' >event with the same payload of an array of dates. In my listening class, >I >dont want to have to deal with having Component1.DATE_RANGE_CHANGED vs. >Component2.DATE_RANGE_CHANGED >vs. any other additional view components that may be built in the future. > >The same way, I can bubble up the event from my view component and add a >listener on a ancestor higher up in the view heirarchy so that I dont have >worry about the type of component that dispatched the particular event. > >Micro-frameworks like PureMVC, etc. try to solve this problem by creating >a >Notifications.as class and list every event (notification) name in that >class. This would probably be the only additional dependency needed, >rather than depending on the classes that dispatch the events.
Well, the notion of “every” doesn’t sound scalable to me, but you are right about the class dependency. However, do you really run into two components dispatching the same event with different meanings in real life? I wonder if there is some way we can define constants on an Interface. -Alex
