The issue with SOLID is not that it's wrong or outdated, it's that some people think it's something you learn in five minutes by reading its Wikipedia page, whi

The issue with SOLID is not that it's wrong or outdated, it's that some people think it's something you learn in five minutes by reading its Wikipedia page, which it isn't. It takes a lot of effort to develop skills to adopt SOLID effectively. > When I look at SOLID, I see a mix of things that were once good advice, patterns that apply in a context, and advice that is easy to misapply. I wouldn’t offer any of it as context-free advice to new programmers. Off course! I wouldn't offer any OOP architectural/programming principle as context-free advice to new programmers. It's easy to misinterpret it if you don't contextualize it, show how it's used in real projects, discuss advantages and disadvantages, and so forth. > The Single Responsibility Principle says that code should only do one thing. Another framing is that it should have “one reason to change”. I called this the “Pointlessly Vague Principle”. What is one thing anyway? This gives me the impression that the author indeed misinterpreted this principle, just to name one, oversimplifying it. If you like the author have trouble understanding the Single Responsibility principle, take a look at "On the Criteria To Be Used in Decomposing Systems into Modules" by David Parnas [1]. It seems to me that the author also oversimplified the other principles as well, maybe on purpose, for using controversy to attract attention to his post. [1] https://www.win.tue.nl/~wstomv/edu/2ip30/references/criteria_for_modularization.pdf https://www.win.tue.nl/~wstomv/edu/2ip30/references/criteria...