De-mystefying coupling

Some of the noteworthy observed during Coupling.
Coupling issues generally come to the fore front while designing using tier architecture.

The following are the lessons learnt

1.When trying to decouple it is always better to attempt decoupling on a Higher level .This would identify and seperate the functionality beforehand.

2. As MartinFowler points out the key is to find out dependancy and once this is achieved try and insulate the modules by using the mapper,This mapper implemented as (preferably) an interface , would be defined in an another package thus providing diff behaviour.

3. We can say objects are tightly coupled when we see import javax.servlet.* in the Action classes where we are implement business logic.

4.Using DTO as means of carriers of data will reduce coupling


5.Avoid cyclic dependancies (identify them early in the lifecycle)

Used and Abused
Perhaps in the most frequently abused words list i find 'process' to be the leader.The underlying meaning of the word seems to be forgotten long ago, instead more often it serves as a safe haven for people who seem to be awed with the technology and do not wish to consider the change.
Process in the first place must serve to accomplish a given task more quickly ,more efficiently not generate tens of documents consuming more time than the task to be accomplished . Added to this formatting the documents is a pain more than anything else
I like programming for the sheer joy of doing it and so generating documents for the sake of process is not my cup of tea.
Well keep watching this space for more ....