SOLID principles are just that: principles!

I love the SOLID design principles. It’s a pity that there is a lot of “hate” towards them, and I think it’s mostly because they are pushed as a dogmatic way of developing software, as a set of inflexible rules that need to be respected at all costs.

That pushes people away from seeing and understanding how useful these principles are. And that’s exactly what they are: a set of principles. It’s literally in the name. But I’m not here to regurgitate, yet again, what SOLID means or represents. I think that every programmer, eventually, will learn exactly that. But take that knowledge for what they are: principles!

My love for is exactly in that nuance. They help me guide my applications’ architecture, but I don’t feel bad if a function or class has more than one responsibility, or if I decide to modify them instead of extending their functionality, or if I’m not adhering completely to every other principle. But I know and respect that those principles exist for valid reasons: to develop manageable and extensible software.

But I’m also not naive to the point of not understanding that there are many possible contexts, be it architecturally or because of team dynamics, in which one might consciously need to decide that it can’t or shouldn’t be done now.

And that is totally fine. Perfection is a lie.