Loose Coupling

Loose coupling is a practice that very strongly compliments OO principle “Programming against Interface, and not against an Implementation”. Two components are said to be loosely coupled when then are developed as interfaces that can be used for transferring data between the two. This involves lesser risk to the fact that change in one would lead to a change in the other module.

In Flex world, you can achieve loose coupling either by using Interfaces or by Events. Both, are very effective ways of getting around the same problem. People like me coming from Java/C# background find it easier to work with Interfaces due to our long association with the concept.

I personally have started to like events a lot better, we they make the components truly loosely coupled. By defining an event on a component, you do not have to worry about coding against an interface. All, you should be aware of is the event that component exposes. You can dispatch the event and you would be done. Let is see how this helps, by way of an example:

<mx:application xmlns:mx=”http://www.adobe.com/2006/mxml”&gt;



private function onClick():void


// do something/anything




<mx:Button id=”btn1″ click=”onClick();” />


You would notice that when the button was created (by Flex library), it just exposes an event that you can handle. Rest is taken care by the framework and you do not have to worry about any interface, yet you can use the same component anywhere you want to.

A very trivial, yet a very essential best practice. Also read my entry on best practices.

3 thoughts on “Loose Coupling

  1. I agree that events are great. 2 issues I have found with using events in practice:

    1) Event driven code can be harder to debug, since there are no explicit function references between the 2 objects, so ‘F3’ doesn’t work. This means it can be hard to figure out what code is firing/listening to the events.

    2) One of the most cumbersome aspects of event driven code is that the listener object needs an explicit reference to the event source object in order to initialize the listener. If the classes don’t have a simple relationship this can be tricky. An example is a button object that is buried deep in a UI object hierarchy that needs to talk to some other UI component that is buried in some other UI hierarchy. For this reason I like to use singletons (probably more than is recommended) for UI dev. The singletons act as event ‘gateways’ that can be accessed easily from anywhere in your code.

  2. Felix,

    1. This is a trade-off, if you choose to get into loose coupling and code re-use then anyways debugging gets difficult. That is why you need good and well defined practices so that you should know how the code is behaving

    2. While I agree that Singletons, act as “Gateways”, there is a caveat that I hope you are aware of. If you have two buttons that have listeners on a singleton. Now when you dispatch an event to the Singleton, both the components will respond – something that you would not want to do. I do not find any Singleton being used by Flex hence, I tent to stay away from Singletons when it comes to views.

    I have reached a point when I can make some recommendation on this one as well – but you will have to wait for a while.

Initiate your idea here...

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s