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.
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.
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
Oh man. It was really simple illustrations but it was more useful, than thousands words! You really have a talent to explain such abstract thing. Hope you will continue to create in the future
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
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!
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.
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.
Please keep making more videos. This content is some of the best I've seen
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
I really appreciate your concise and easy-to-understand way of speaking.
Oh man. It was really simple illustrations but it was more useful, than thousands words! You really have a talent to explain such abstract thing. Hope you will continue to create in the future
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
Great explanation! I hope you continue making videos. Thank you
This was incredibly well put together. So easy to follow! Commenting just to feed the algorithm and encourage you to keep making videos
Clear concise explanation! Thank you!
Very good explanation, please continue!
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!
Very nice explanation, thank you!
perfect content body.
a big thanks to u, keep going 💪
Nice one! Can you tell me which program do you use for this kind of animations?
I used Adobe After Effects then combined everything in Premier.
Clear explanation, thank you very much
Your content is great
Good video, thank youy very much!
excellent
Good video.
Loved this, thanks
loosely coupledinformatin system architecture enables teh separate developmenbt, testing and deployment of service compoenents.
good video, thx