Loose Coupling = Awesome

Tight Coupling Loose Coupling
Translator

Working Together
When rst approached, loosely coupled systems may seem confusing but the complexity may not justify itself until something goes wrong, or a change needs to be made in the architecture. In this example, by setting up communication between parties with a translator, it doesn’t just make things easier for discussion, it anticipates a scenario where one parts needs a fundamental change. Because neither party isn’t required to have a connection method (language) specialized to their colleague, a change in one part of the system doesn’t a ect the other part.

Russian Engineer

French Designer

Russian Engineer

French Designer

The French designer learns Russian to communicate with the engineer

Both parties communicate. Either can be swapped without breaking communication. Translator

Chinese Engineer

French Designer

Chinese Engineer

French Designer

Now the French designer must learn Chinese to communicate.

The designer doesn’t need to acknowledge the change of the engineer’s language.

This sucks.
With tight coupling, each party must have a specialized knowledge of the other in order to work together.

This is better.
With loose coupling, neither the designer nor engineer needs knowledge of each other’s method of communication. They just communicate.

Real World Example
Tight Coupling Loose Coupling
ORM

Working Together
In a real world application, Django and other advanced technologies use Object Relational Mapping (ORM) to turn data into objects. Each party’s responsibility is simply to communicate with the ORM. The implications of this are that something as drastic as switching out the database technology wouldn’t even be noticed by Django. This transition is so easy, two servers running the same application could be using two di erent databases. In the reverse, the same data could be accessed by a di erent framework and di erent code, as long as it refers to the same ORM.

MySQL

PHP

MySQL

Django, et al.

PHP gets data from MySQL by calling MySQL requests thorughout the code.

The ORM instantiates data as objects, written to and read from MySQL and Django. ORM

MongoDB

PHP

MongoDB

Django, et al.

The code must now be pruned for MySQL requests, rewritten, and retested.

The ORM loads data into the same objects but from MongoDB. No Django code is changed.

This sucks.
You are not free to replace parts of the system without breaking another part.

This is better.
Both parties refer to a common model so each party can be changed without breaking the chain.

Sign up to vote on this title
UsefulNot useful