Disclaimer: Although I’ve studied basic design patterns and will soon be studying refactoring techniques, I am not an expert on software engineering (yet). This article represents some of my current thoughts about decoupling architectures and they may not be fully accurate. If you disagree with me, I would be more than happy to hear your thoughts and make improvements to this article.
To decouple is to separate something from something else *. We can decouple a car’s steering wheel from the car by removing its steering wheel; we can decouple one segment of a railway track from another by forcing a space between the two tracks; we can decouple the lenses on glasses from their frames by taking the lenses off. In the previous examples, decoupling seemed to be counterproductive because it broke the car, the railway track, and the glasses.
In programming, to decouple is to do good…is to make components independent of each other…is to design scalable architecture. But wait, if a program’s components are independent of each other
- How can the program even work correctly?
- Why does it make the architecture scalable?
There is word play on the meaning of “independent”. Here, independent components can still have relationships with other components but compared to dependent components, we can more easily modify them to achieve a new goal without needing to modify nearby components. A decoupled or loosely coupled program’s architecture often contains many independent components that work together and when we modify the program (I use “when” instead of “if” because software continuously changes) to fulfill new requirements, we change as few selective components as possible instead of many components. The modified program’s general architecture and the relationships between its components would remain similar to the original program’s.
The opposite of a decoupled or loosely coupled program is a coupled program. A coupled program’s components are heavily reliant upon one another and therefore, modifying the program to achieve a new goal involves modifying many intermingled components.
There are several advantages to building decoupled or loosely coupled programs instead of coupled programs. We can:
- quickly add enhancements to the program, including new features for sudden requirement changes
- more easily debug the program
- more readily envision the big picture/abstractions in addition to the implementations
- gain greater insights into how the program works
- continuously make the program scalable
- greatly enjoy developing and testing the program!
Sometimes, we can apply programming principles to our daily lives by approaching situations with decoupled mindsets. The keyword is “sometimes”. I’m certainly not advocating decoupling our relationships; it’s healthy to be interdependent with each other! However, we can decouple our confidence levels from our accomplishments: what we have done is different from our personalities and one doesn’t need to depend upon another. We can also decouple our physical possessions from our self-image: where there is sufficient risk, never risk your life just to save a bank account. In addition, we can decouple what we want to do, our personal goals, from what other people want us to do: pursuing a goal because we believe it is intrinsically meaningful is way more fun than pursuing it because someone says we should pursue it.
Building programs with decoupled or loosely coupled components is advantageous for our code! At times, thinking with decoupled or loosely coupled mindsets is advantageous for ourselves!
_______________________________________
* Oppositely, to couple is to be together, such as a couple!