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" <[email protected]> >>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 >>[email protected] >>http://chattyfig.figleaf.com/mailman/listinfo/flashcoders >> _______________________________________________ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
