Re: [Flashcoders] one class listening for another classes dispatchedevent
If like you said, --totally tightly coupled solution is overkill.-- ,than I can agree with you :P But alright, to plug in on this matter. As I found out it's not hard to lose the tight coupling. The hard part is to find a system that works fast and intuitive for you. Once you found or created one, you'll be happy to reuse that system, even for simple setups and for the simple reason that it is YOUR OWN ( or preferred ) loosely coupled (event) system. At that click you will find out that it that it can work more for you than against you or against your speed. Integrating a loosely coupled flow also helps you in creating your own app-paradigm and workflow and enables you to start or reopen a project faster. You now know the best place to implement and to listen for that shout. And a lightyear later when you look back into your crappy-small-app code of the past, you will smile and think: Nice try but I know better now ;) Latcho Matt Folkard wrote: I completely agree with this as I've been in exactly the same situation with a largish scale project. The sort of projects I tend to do are small scale games for which the *totally tightly coupled solution is overkill*. However, I've eaten my words on that point as well... On 17 Nov 2009, at 21:05, Mendelsohn, Michael michael.mendels...@fmglobal.com wrote: Alright, since I asked the question, I'm piping in. I just finished a project that became immensely complicated precisely because I eventually had everything tightly coupled. Had I used custom events and done some other things from the get go, I'm nearly certain it would have been easier to do my updates. With the tight coupling of that project, it would be difficult for anyone else to go into it in the future. In smaller one-off projects, I don't think it's a big deal, but I'm trying to force myself to get in the habit of loosely coupling everything, via custom events. - MM ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] one class listening for another classes dispatchedevent
Tight coupling is not as bad as people make it out to be. Yes it is. Jason Merrill Bank of America Global Learning Learning Performance Soluions Join the Bank of America Flash Platform Community and visit our Instructional Technology Design Blog (note: these are for Bank of America employees only) ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] one class listening for another classes dispatchedevent
Merrill, Jason wrote: Tight coupling is not as bad as people make it out to be. Yes it is. No, it is not. Btw, thanks for your very stimulating response. Meh, I get to argue for my point first then. Tight coupling can be an issue, if the coupled components shouldn't be coupled. It is not an issue at all if they more or less couldn't work without something doing the job of the other and few if any replacement options. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] one class listening for another classes dispatchedevent
On Tue, Nov 17, 2009 at 8:06 PM, Henrik Andersson he...@henke37.cjb.net wrote: Tight coupling can be an issue, if the coupled components shouldn't be coupled. It is not an issue at all if they more or less couldn't work without something doing the job of the other and few if any replacement options. In which case they're actually one component, conceptually - if the dependencies are really that inextricable. :o) Ian ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] one class listening for another classes dispatchedevent
Ian Thomas wrote: In which case they're actually one component, conceptually - if the dependencies are really that inextricable. :o) Two sub modules in a webbrowser is a http client and an image parser. Yet, they need to cooperate for images to download while being displayed. When do you draw the line? How does submodules interact with this rule? In the end, you need to start focusing on the individual case. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] one class listening for another classes dispatchedevent
*blink* But those two components should not be tightly coupled. Bad example, I think. The HTTP client doesn't depend on the image parser; it's used to provide HTTP services to a number of different components of a browser. You could use the HTTP client code in complete isolation from knowing anything about images - it might not even be used for a visual browser. Exchanging data via HTTP is all it should do and all it should care about. As for the image parser, it's likely you'd have more than one image parser - one for PNG, one for GIF, one for JPEG and so on. They don't care whether they're parsing data fetched from an HTTP client or from a local file. They just parse data. The browser itself connects up the pieces. As I've already pointed out, think of a browser displaying a local JPEG image. The HTTP client code isn't even involved in that process. Then think of a browser fetching, say, a text file. The image parser isn't involved in that process. I'm not saying you _couldn't_ write a browser where the two were inextricably connected, but that's just poor design, it really is, if you ever want to reuse any of your code or extend your browser in any way. Perhaps you can give a better example :-) Ian On Tue, Nov 17, 2009 at 8:34 PM, Henrik Andersson he...@henke37.cjb.net wrote: Ian Thomas wrote: In which case they're actually one component, conceptually - if the dependencies are really that inextricable. :o) Two sub modules in a webbrowser is a http client and an image parser. Yet, they need to cooperate for images to download while being displayed. When do you draw the line? How does submodules interact with this rule? In the end, you need to start focusing on the individual case. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] one class listening for another classes dispatchedevent
Alright, since I asked the question, I'm piping in. I just finished a project that became immensely complicated precisely because I eventually had everything tightly coupled. Had I used custom events and done some other things from the get go, I'm nearly certain it would have been easier to do my updates. With the tight coupling of that project, it would be difficult for anyone else to go into it in the future. In smaller one-off projects, I don't think it's a big deal, but I'm trying to force myself to get in the habit of loosely coupling everything, via custom events. - MM ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] one class listening for another classes dispatchedevent
Ian Thomas wrote: stuff My point is that things that can seem unrelated can have a direct relationship anyway. The image parser can run alone, yes. But it needs to cooperate with the http client module if you want to show the image while it is still loading. That was my point of the example, to show that things that work well alone can work even better if they cooperate. Anyway, one thing for certain, most people would agree that it's kinda silly to write a full event dispatching job when all you wanted was to start an animation in the movieclip behind you. I am not saying that it's a bad idea to keep things reasonably separated, but I am saying that it is a bad idea to keep them too separated as well. Integration is important for usable applications. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] one class listening for another classes dispatchedevent
Sorry, we're way off topic here. :-D I'll shut up. Ian On Tue, Nov 17, 2009 at 9:05 PM, Mendelsohn, Michael michael.mendels...@fmglobal.com wrote: Alright, since I asked the question, I'm piping in. I just finished a project that became immensely complicated precisely because I eventually had everything tightly coupled. Had I used custom events and done some other things from the get go, I'm nearly certain it would have been easier to do my updates. With the tight coupling of that project, it would be difficult for anyone else to go into it in the future. In smaller one-off projects, I don't think it's a big deal, but I'm trying to force myself to get in the habit of loosely coupling everything, via custom events. - MM ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] one class listening for another classes dispatchedevent
I completely agree with this as I've been in exactly the same situation with a largish scale project. The sort of projects I tend to do are small scale games for which the totally tightly coupled solution is overkill. However, I've eaten my words on that point as well... On 17 Nov 2009, at 21:05, Mendelsohn, Michael michael.mendels...@fmglobal.com wrote: Alright, since I asked the question, I'm piping in. I just finished a project that became immensely complicated precisely because I eventually had everything tightly coupled. Had I used custom events and done some other things from the get go, I'm nearly certain it would have been easier to do my updates. With the tight coupling of that project, it would be difficult for anyone else to go into it in the future. In smaller one-off projects, I don't think it's a big deal, but I'm trying to force myself to get in the habit of loosely coupling everything, via custom events. - MM ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
