Avoiding Premature Software Abstractions

Re:Avoiding Premature Software Abstractions by mevorah on Sunday November 21, 2021 @01:44PM (#29298617)

This left me with mixed feelings. On one hand, I see great value in single responsibility abstractions - they can improve readability (when looking at a single class that leverages them), and they can make components easier to test. On the other hand, I’ve coached a number of teammates over the years on SOLID principles and have continuously been met with push back or inappropriate abstractions (in my opinion).

A big lesson learned for me has been that there are multiple ways to do something - not everyone will have the same mental model as me. Going further, the more granular your mental model (I.e the more abstractions), the higher the chance that other teammates’ mental models will differ.

I still like abstractions for testability reasons - perhaps this is the right smell to check for when determining whether to split something up.

[ Parent | on HN ]

Re:Avoiding Premature Software Abstractions by rapnie on Sunday November 21, 2021 @02:08PM (#29298806)

> Going further, the more granular your mental model (I.e the more abstractions), the higher the chance that other teammates’ mental models will differ.

Agree to an extent. What I tried to explain in my other comment is that having full abstraction here, half-way abstraction there, and a different partial abstraction somewhere else also weighs on the mental model you need to have of the codebase.

That might be an argument to muster the dilligence and discipline to have more of the same abstractions consistently for similar concepts (excepting those that are obviously superfluous, of course).

[ Parent | on HN ]