Особо ничего не изменилось, логика кода внутри метода будет точно таким же. Даже если я буду принимать данные/зависимости в конструкторе, мой метод остается неизменным, разве что в конструкторе я опять же буду вызывать модуль генераций хеша, тогда вопрос будет немного задан по другому: - "А правильно ли что в экземпляре класса я дергаю модуль генераций пароля?".
Поэтому мой вопрос был задан в простом формате вынести модуль генераций хеша пароля (из куска кода, который взаимодействует с пользователем) или нет aka Должен ли этот метод тогда только уметь обновлять данные тем самым получив в параметрах этот hash, а не самому создавать его.
У тебя есть другой ответ?
mkone112, ну значит ты слит раз не смог с 3-ей попытки аргументировать свои слова и наверное пишешь код в таком стиле: раз код не по ооп значит единая ответственность не распространяется, гений мыслей.
mkone112, ты очень душный. Судя по комментариям и ответам других людей тебе все уже разложили по полочкам с довольно приемлемым примером, но ты всё отстаиваешь свою позицию как "клоун" без каких либо аргументов, видно что поддержка явно не на твоей стороне. В принципе таких как ты наверное лучше сразу кидать в игнор. В диалоге с такими обычно ничего не добьешься и не объяснишь.
Я ещё раз повторюсь, твоя цитата
SOLID обычно применяется к ооп, я не вижу здесь ооп.
к вопросу ТС звучит как бред не в тему или как сказал Дмитрий
На мой взгляд, небольшое нарушение в том, что модуль самостоятельно резолвит свою зависимость от UserRepo, а не получает её через DI. От Password, наверно, тоже, но это вроде как утилита и можно не заморачиваться. А вот UserRepo я бы заинжектил.