As a Java engineer in the web development industry for several years now, having heard multiple times that X is good because of SOLID principles or Y is bad because it breaks SOLID principles, and having to memorize the “good” ways to do everything before an interview etc, I find it harder and harder to do when I really start to dive into the real reason I’m doing something in a particular way.
One example is creating an interface for every goddamn class I make because of “loose coupling” when in reality none of these classes are ever going to have an alternative implementation.
Also the more I get into languages like Rust, the more these doubts are increasing and leading me to believe that most of it is just dogma that has gone far beyond its initial motivations and goals and is now just a mindless OOP circlejerk.
There are definitely occasions when these principles do make sense, especially in an OOP environment, and they can also make some design patterns really satisfying and easy.
What are your opinions on this?
The SOLID principles are just that principles, not rules.
As someone else said, you should always write your code to be maintainable first and foremost, and extra code is extra maintenance work, so should only really be done when necessary. Don’t write an abstract interface unless multiple things actually need to implement it, and don’t refactor common logic until you’ve repeated it ~3 times.
The DRY principle is probably the most overused one because engineers default to thinking that less code = less work and it’s a fun logic puzzle to figure out common logic and abstract it, but the reality is that many of these abstractions in reality create more coupling and make your code less readable. Dan Abramov (creator of React) has a really good presentation on it that’s worth watching in its entirety.
But I will say that sometimes these irritations are truly just language issues at the end of the day. Java was written in an era where the object oriented paradigm was king, whereas these days functional programming is often described as what OO programming looks like if you actually follow all the SOLID principles and Java still isn’t a first class functional language and probably never will be because it has to maintain backwards compatibility. This is partly why more modern Java compatible languages like Kotlin were created.
A language like C# on the other hand is more flexible since it’s designed to be cross paradigm and support first class functions and objects, and a language like JavaScript is so flexible that it has evolved and changed to suit whatever is needed of it.
Flexibility comes with a bit of a cost, but I think a lot of corporate engineers are over fearful of new things and change and don’t properly value the hidden costs of rigidity. To give it a structural engineering analogy: a rigid tree will snap in the wind, a flexible tree will bend.