Coupling is a term that describes the relationship between two entities in a software system (usually classes).
When a class uses another class or communicates with it, it’s said to depend on that other class, and so these classes are coupled. At least one of them knows about the other.
Coupling describes the degree of dependency between one entity to another entity. Often classes or objects.
But, the idea is that we should try to keep the coupling between classes in our systems as loose as possible. Loose coupling or sometimes decoupling (although in English decoupling would mean no coupling at all, people often use it to imply loose coupling between entities).
We said earlier that “Coupling describes the degree of dependency between one entity to another entity.” Often for classes or objects.
So, what is loose-coupling versus strong coupling in practice, and why should we make entities loosely-coupled?
When ClassA depends heavily on ClassB, the chances of ClassA being affected when ClassB is changed are high. This is strongly coupled. However if ClassA depends lightly on ClassB than the chances of ClassA being affected in any way by a change in the code of ClassB, are low. This is loosely coupled or a decoupled relationship.
Loosely coupled or a decoupled relationship is good because we don’t want the components of our system to heavily depend on each other. We want to keep our system modular. Where we can safely change one part without affecting the other. When two parts are loosely coupled, they are more independent of each other and are less likely to break when the other changes. Strong coupling usually occurs when entity A knows too much about entity B. If entity A makes too many assumptions about how entity B operates or how it is built. Then there is a high risk that a change in entity B will affect entity A. This is because one of it’s assumptions about entity B are now incorrect.
An important technique to achieve loosely coupled is Encapsulation. The idea is that a class hides it’s internal details from other classes and offers a strictly defined interface for other classes to communicate with it.
So for example, if you were defining a class Car, it’s interface (public methods) would probably be,
getSpeed() These are the methods other objects can invoke on Car objects.
All of the other details of the Car class: how the engine works, kind of fuel it uses, etc. are hidden from other classes – to prevent them from knowing too much about Car.
The moment class A knows too much about class B we have a strongly coupled relationship, where class A is too dependent on class B and a change in class B is likely to affect class A. Making the system hard to expand and maintain.
A relationship between two entities, where they know little about each other (only what’s necessary) – is a loosely coupled, or decoupled relationship. And when we have two entities that know too much of each other then we have a strong coupled relationship.
For example, one of the most popular design patterns for web development (MVC) is all about decoupling.
Having code that is modularized and decoupled will make your code more understandable, more testable, and more maintainable, no matter what programming domain you are working in.