Thanks so much for the extra information... and in fact you are correct, in the project that I am working on there are 4 main components that have to be as loose as possible but again those 4 classes use other classes where the communication has to be tight which at first glance I was just seeing the bigger picture hence I was wondering if the 4 major components had to be tied or loose.
On 1/18/08, Merrill, Jason <[EMAIL PROTECTED]> wrote: > > Well good post, I guess I just mean in general, you should think of > loosely coupling where you can, and tightly coupling where appropriate. > I too have tight coupling dependancies in my applications, it' s hard to > get around it. > > Jason Merrill > Bank of America > GT&O L&LD Solutions Design & Development > eTools & Multimedia > > Bank of America Flash Platform Developer Community > > > > > > >>-----Original Message----- > >>From: [EMAIL PROTECTED] > >>[mailto:[EMAIL PROTECTED] On Behalf > >>Of Paul Andrews > >>Sent: Friday, January 18, 2008 12:32 PM > >>To: Flash Coders List > >>Subject: Re: [Flashcoders] Dispatch or Call? > >> > >>----- Original Message ----- > >>From: "Merrill, Jason" <[EMAIL PROTECTED]> > >>To: "Flash Coders List" <flashcoders@chattyfig.figleaf.com> > >>Sent: Friday, January 18, 2008 12:33 PM > >>Subject: RE: [Flashcoders] Dispatch or Call? > >> > >> > >>> Well, it may seem like extra work, but by tying in directly > >>to the other > >>> classes, you're tightly coupling your framework, which is not good > >>> practice. It's best to have classes not have to know about other > >>> classes, so your framework is loosely coupled, which often > >>means writing > >>> a lot of your own custom listeners. > >> > >>I don't think there's an absolute rule about this. It's not > >>intrinsically > >>bad to directly couple classes - if it were we would be > >>unable to write > >>software. Imagine only communicating with a String object by events! > >> > >>Whether or not classes should be directly coupled or not is really an > >>architectural decision. I'm using Flex more than Flash these > >>days, but the > >>architectural decision aren't wildly different. > >> > >>My data model is tightly coupled - classes refer directly to > >>other classes. > >>The user interface is loosely coupled with the interface > >>communicating with > >>the data model via the event mechanism. Changes made to the > >>data model can > >>be communicated back to the interface via the event mechanism > >>(there's also > >>a direct binding mechanism often used in Flex in place of the event > >>mechanism). > >> > >>In this manner the UI is losely coupled building blocks that > >>doen't have any > >>dependence on other parts of the UI. The data model on the > >>other hand is > >>closely coupled. > >> > >>Although the data model is closely coupled it also uses events to > >>communicate asynchronously with other services for communication/data > >>persistence etc. > >> > >>To say any more besides this gross simplification would lead to an > >>architecture discussion. > >> > >>So, close coupling is not evil, but the event mechanism > >>should also be used > >>for separating the application architecture. > >> > >>Paul > >> > >> > >>> > >>> Jason Merrill > >>> Bank of America > >>> GT&O L&LD Solutions Design & Development > >>> eTools & Multimedia > >>> > >>> Bank of America Flash Platform Developer Community > >> > >>_______________________________________________ > >>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 > -- ...helmut _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
