Comment by Cpoll
5 days ago
Uncle Bob does a bad job talking about trade-offs, but there's still value in stuff like SOLID. The problems start when people blindly obey or ignore design principles.
Saying SOLID makes bad code is as over-simplistic as saying SOLID makes good code.
The trouble with SOLID is that it's mainly an artifact of old languages and paradigms.
3 of the letters are almost irrelevant in modern code, or barely worth thinking about most of the time.
So what's the value here? Single responsibility?
That kind of thing is now so known that it doesn't really need talking about, like you don't really need to endlessly discuss the database normal forms like people did in the 00s.
Concepts that are worth explaining to beginners, but most code will follow it by default.
Seeing it in job descriptions is more an indicator that a company has an inexperienced lead more than anything else.
Single Responsibility was written about nearly 40 years after cohesion was grafted into software design from an actual architect's (like buildings and cities, absolutely not software o doctoral thesis.
"That kind of thing is now so known that it doesn't really need talking about, like you don't really need to endlessly discuss the database normal forms like people did in the 00s."
Has humanity progressed so much that we no longer forget the lessons of the past?
That would indeed be a good thing but I am not so sure of it.
On the contrary, the new trend of telling a bot to write code automates disregard for architecture.
> So what's the value here? Single responsibility? That kind of thing is now so known that it doesn't really need talking about
Except I see people getting it wrong constantly, even in the comments here. Its not about keeping code together that's related in functionality, this about keeping code separate by stake holder. For example, if you have two bosses that keep asking for changes related to their departments, you keep their relevant code separate, so when you have to keep updating it for one boss, you don't break the code related to the other boss, and vice versa.
Does it work? I don't know, never been in this situation.
https://en.wikipedia.org/wiki/Single-responsibility_principl...
If single responsibility is so well known, when did I just this week see some code that violated that from a senior engineer? That code past review by a couple other programmers, without me looking at it and pointing out how horrible it was.
And I saw a "senior" engineer make a database table without foreign keys just 3 years ago.
Some people are just bad.
Doesn't change my point that the debate is long settled, SRP is incredibly well known and the de-facto way of coding today.