RE: [Flashcoders] one class listening for another classesdispatchedevent

2009-11-18 Thread Merrill, Jason 
My feeling is if the two components are related enough that tight
coupling is the desired option, then they really should be the same
single class.  If that makes it so there would be too much code in one
class and the tasks so different, then they should be in separate
classes with events dispatched and listened to.  


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)





-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Latcho
Sent: Wednesday, November 18, 2009 9:25 AM
To: Flashcoders mailing list
Subject: Re: [Flashcoders] one class listening for another
classesdispatchedevent


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
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Re: [Flashcoders] one class listening for another classesdispatchedevent

2009-11-18 Thread Henrik Andersson 

Merrill, Jason wrote:

If that makes it so there would be too much code in one
class and the tasks so different, then they should be in separate
classes with events dispatched and listened to.



So you are basically saying that every single time you want to use 
something in another class, you should dispatch an event.


I say, that's obviously not correct and you agree with me here, using 
events for everything is stupid.


My view is that when a class provides some service for other classes, do 
use it.


Just remember who is responsible for what.
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

RE: [Flashcoders] one class listening for another classesdispatchedevent

2009-11-17 Thread Merrill, Jason 
 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.

That's a strange point of view, I would love to see a good example of
that.  If you've got a system designed that way, then you've got bigger
problems.  IMO, tight coupling is the best way to complicate things, not
the other way around.  The point is, the default position should be to
loosely couple your code unless you have good reason to do otherwise.
The default position should not be to tightly couple your classes unless
you see a reason to do otherwise. 

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