User берет, т.к. он знает че использовать, если бы было чем-то типа auth->authenticate в user, то ещё можно было бы глаза закрыть, т.к. usrr не знает что происходит, а так он знает и чтобы изменить поведение надо в него лезть (а не стандартные функции переписывать), а т.к. user уже за другое ответственен, то у него много ответствен гостей появляется, т.е. нарушение

Смену пароля надо в user, т.к. это просто один из атрибутов user, но здесь только смена, отправка нотификаций и прочее - за пределами user

В пользователе только смена, ar мне не нравится, поэтому сохранение в репозиторий, а все проверки до фактической смены в отдельном сервисе

Надо сменить проверки - меняем только сервис, остальное без изменений

Давай начнём с самого начала - зачем нужны паттерны? Точнее для чего они?

Это кто сказал? ))) не верь ему )

Это кто сказал? ))) не верь ему )

Верить вам или людям с опытом работы в 10-20 лет в индустрии.. хм... сложно выбрать.

Паттерны - это решение какой-либо проблемы. If/else - это частный случай, т.к. они тоже являются проблемами

Юнит - легко, у меня может быть несколько аутентификации и каждая будет протестирована, каждую можно будет использовать и это легко поддерживать

мое любимое определение - паттерны это способы избавления от switch

только и всего?

Юзер не должен проверять пароль, сделай отдельный классы UserInput

вывод, паттерны способ убрать switch/if/new и добиться соблюдения OCP

Это частный случай, он не должен распространяться на все, т.к. ограничивает применение

вывод, паттерны способ убрать switch/if/new и добиться соблюдения OCP

кроме юзера пароля никто не знает

кроме юзера пароля никто не знает

т.е. речь о авторизации сейчас или о вводе пользователя?

Он тоже пароль не знает, пароль хеширован (если на всякий случай не хоронить и открытую версию)))

Я вот не согласен с таким определением. Да они помогают избавлятся от if/else но они не для этого

только юзер знает какой у него сейчас пароль. Соответсвенно он должен решать правильно он введен или нет

Ну это да, а если я хочу поменять пароль и насетить вместо старого пароля ерунду какую нибудь?

оно конечно сильно упрощено, но это намного лучше чем "решение какой-то проблемы"

Д - делегирование ответственности

Я вот не согласен с таким определением. Да они помогают избавлятся от if/else но они не для этого

Но полностью от if'ов же не избавиться?

Кто-то говорил, что static - это..

if (!password_verify($this->password, $oldPassword)) { throw new IncorrectPasswordError(); } повтор кода

придумай мне кейсы при которых мне надо будет поменять этот код

Пароль не должен быть простым, пароль хэшируем, пароль хэшируем методом из конфига. Самое простое

DRY не о том что бы маниакально убирать дублирование, он о том что бы логика не дублировалась

В конфиге указано чем хэшировать ))

Пароль не должен быть простым, пароль хэшируем, пароль хэшируем методом из конфига. Самое простое

Раз уже изменили ))

Так вот для этого и rsp, чтобы не менять 100 классов, а просто добавить один и передать его там где он нужен. А мы уже на один больше изменили. Последний пример мне нравится больше

короч SRP = single reason to change.

это называется преждевременной оптимизацией

Возможно, у меня бы был класс в котором этот же код из user, надо изменить - изменил бы его. У меня меньше изменений потребовалось бы, про это паттерн и говорит