Потому что SRP не про то, что класс должен делать что-то одно)

"Принцип единственной ответственности" - о чем тогда?

Я именно так считаю, ну ок. Сколько людей, столько мнений

да все так считают) в том и прикол

единицы читали первоисточник, да и после прочтения не все осознали разницу...

Роберта Мартина книга "Чистая архитектура", он там описывает принципы SOLID на примерах. Это первоисточник, так как Мартин и есть автор SOLID.

Поясни разницу

Если кратко, то классы должны служить одной бизнес-цели и меняться согласованно.

Иначе, будет так, что ты допустим отрефакторил корзину, а у тебя перестала работать авторизация. Потому что класс отвечал и за корзину и за авторизацию.

У меня гора таких случаев в практике была, поэтому я SRP свято чту )

Но ты же выше писал "Потому что SRP не про то, что класс должен делать что-то одно)"

Как понимают это обычно программисты. Они читают по кривому пересказу из вторых рук, либо просто трактуют по своему название, в котором упонимается "единая ответственность".

При этом, программистам ближе именно техническая часть приложения, поэтому они автоматом относят к ответственности класса именно технические аспекты, а не бизнесовые.

То есть, в понимании программиста, когда он говорит об ответственности класса, он имеет в виду "этот класс ходит в бд" или "этот класс работает со строками".

В SRP же под ответственностью подразумевается бизнесовая ответствееность - что заявки принимаются сайтом, что он корректно применяет скидку, что счëт отправляется клиенту, в общем всë что программирования не касается.

Я могу подробнее, но у меня столько текста не поместится, это надо отдельную видеолекцию записать)

Здесь я так сделал, чтобы полноценного юзера можно было через конструктор создать. Сервис я делать не стал. При усложнении логики надо делать сервис и зависимости внедрять в него

Понял, спасибо!

да, он не про то) в том и подвох, все кто первоисточник не читал естественным образом его упрощают, и трактуют в корне неверно)

Всë бы ничего, но привыкшие к неверной трактовке SRP программисты начинают "применять" его там где он не нарушен, и дробить классы на мелкие части, излишне усложняя код.

"Вот в этом классе есть валидация и запросы к апи, поэтому я сделаю три класса, валидатор, апи и менеджер который будет их координировать".

Когда такое стремление к раздроблению классов сочетается с любовью к использованию наследования, получается вообще жесть.

В этом случае получается, что популярное мнение AR нарушает SRP- неверное?

Оно же выполняет свою бизнес логику так сказать

Прелесть любого из принципов SOLID в том, что применение любого из них достаточно легко обосновать, если он нарушен.

Грубо говоря, ты можешь сделать вывод, в чëм именно конкретный вред от нарушения SOLID в этой части проекта с бизнесовой, а не программистской точки зрения.

Эти принципы придуманы для того, чтобы не страдал бизнес)

Неверное, да. АР не нарушает SRP, я использую его везде и всë отлично

Все зависит от того, как определить ответственность. Если ответственность - магазин должен работать, то можно вообще все в один класс запихать 😁

Но его бездумное использование может привести к быстрому нарушению SRP, если всë в него попытаешься запихнуть)