Loose vs Tight Coupling

In software engineering, we sometimes refer to code as being loose or tightly coupled. In this video I cover the details of what software engineers mean by both coupling and cohesion as well as dive into a specific example so the terms aren’t just abstract.

Finally, I risk going to engineering hell by suggesting you don’t always need to make your code loosely coupled! Engineering is about tradeoffs and I cover what tradeoffs I see as well as the questions I like to ask myself when deciding how loosely coupled to make my code.

0:15 - Coupling
0:43 - Cohesion
1:07 - Benefits of Loose Coupling
1:37 - Example
3:25 - Tradeoffs
4:35 - Questions to help measure tradeoffs

[ScottABailey]

A couple things I cut from the video:

Loose vs tight coupling isn’t a strict yes vs no answer. Coupling can exist in a wide spectrum, ranging from all your code jumbled together to highly separated systems. You’re looking for a point on that spectrum where you get the most benefit for your cost. Simple patterns like organizing your code and minimizing function calls between different concerns go a long way and are cheap.

Second, there are different approaches to decoupling code. The example I gave was one approach, but you can imagine many others that range in complexity and level of decoupling. For example, I could have had the file parsers implement a common interface and had the calculate() logic accept that interface as input. I could have used a stream API, callbacks, dependency injection, etc. This goes back to finding the most benefit for the least cost (code complexity) that meets your requirements.

Finally, I sometimes see design disagreements between engineers that devolve into abstract debates about concepts like coupling or separation of concerns. I find these conversions can be more productive if you concentrate on the specific tradeoffs in the case at hand. Different people will make different implicit trade offs, leading them to different designs.

[njdarda]

how are your videos this good right from the get go? this is 4th video on the channel and it's very clear, well animated, helpful and to the point. good job.

[mohamedwalid]

Clear explanation, thank you very much <3

[ScottABailey]

Software Engineer Hell:
- Where the tests always fail… until you run a debugger
- Where it works on your machine but never in prod
- I heard you like abstract base classes. Here’s 20!

[detaaditya]

I think premature abstraction is in fact, a premature optimization - instead of performance, it optimizes for maintainability. So yeah, I agree, don't optimize too early

[nekokobi]

Great explanation! I hope you continue making videos. Thank you

[vikingthedude]

Please keep making more videos. This content is some of the best I've seen

[psychic]

A lot of people learn concepts and use them everywhere they can. I like that you highlight how each decision has trade-offs. This is the reason they call us engineers and this is the reason we are not going to get replaced by AI anytime soon

[ZAKARYAEADMI]

perfect content body.
a big thanks to u, keep going 💪

[HubertoMadalena-rzxs]

loosely coupledinformatin system architecture enables teh separate developmenbt, testing and deployment of service compoenents.

[whataguy]

I really appreciate your concise and easy-to-understand way of speaking.

[Gilb]

Very good explanation, please continue!

[pilchu]

Nice one! Can you tell me which program do you use for this kind of animations?

[OldManGeezuz]

This was incredibly well put together. So easy to follow! Commenting just to feed the algorithm and encourage you to keep making videos