Single Responsibility and dumb objects?

Question

OOP

Tell me where is the line between Single Responsibility and stupid object classes that have practically Zero responsibility. And then we have an "architect", relying on single Responsibility, degenerates everything into stupid people and produces code ... Abstraction and generalization smoke on the sidelines

Answer 1

Read about the law of Demeter . If the project has a lot of calls like

SomeClass.SomeField.SomeMethodWhichReturnsOtherObject().AnyOtherField = 15;

or
a.b.c().d = e.f.h().g;- it is quite possible, in the architecture it's overkill with SR.
Although it is possible that the architect is trying to prepare for all possible changes; SR in this case is only a consequence (one of them), and reasonable arguments will lie outside the SOLID principles.

Answer 2

If a class has one method and no state, then something is wrong.
Those. simple things are better done as functions, and if a thing is simple, but it needs to store state, then classes should already be used.
In general, a lot depends on the language, if one of the dynamic ones, then, roughly speaking, there are only two patterns: DRY and KISS , and it is better to use classes as little as possible.