For those who know nothing about coupling it’s described on the wikipedia as the degree to which each program module relies on each one of the other modules.
Doesn’t ring a bell? Well, I don’t fancy that definition as well. Others have defined it as the level of interdependency between a method and the environment. Maybe this one suits you better.
Associated with this term often comes cohesion. Cohesion relates to the number and diversity of tasks for which a single unit of an application is responsible. It is relevant for units of a single class and an individual method.
After knowing these two concepts it’s fairly easy to understand that we strive for a loosely coupled class structure where objects have high cohesion. This combination normally allows us to perform changes in classes with minimal impact on the overall solution, while creating high quality reusable components.
Just yesterday I saw something on this subject on Web 2.0 Summit – why can’t I go to the good conferences? – coverage on O’Reilly Radar. There I found this image that was taken from Charles Perrow’s Normal Accidents: Living with High-Risk Technologies – no, I don’t think you’ll find this one in the library – that correctly reflects this reality.
So if all of this is so straightforward why am I talking about it? Well as of today I found someone that believes that all of this is wrong. I tried to google it to see if I found such theory but I was unable to. Tight coupling in a complex system!? Ideas anyone?
To finish, and for those of you who are not satisfied with the style (I call it short-and-bad) of this little introduction – or if you just want to learn a little more – you can read chapter 7 of Objects First With Java by D. Barnes and M. Kölling. In my opinion this is simply the best books for OOP beginner. And if you like the book and you want to read the rest of it you have two choices: