пользователь знает, что ему дали "решатель", который решает как то, который можно отменить и узнать о его здоровье

GradientDescent и Gradient штуки разные, может внутри GradienDescentSolver и существует какой то Gradient который может descent, но пользователю GradientDescent это знать не надо

ну тут я бы сказал что концепция объектов немного не подходит. Твоя задача прекрасно ложится на обычные функции

для объектов слишком маленький масштаб. Нужен контекст задачи

Ну да, это стратегии, которые лучше всего выражаются функциями

есть разница как по мне между Loader и UserManager или PasswordVerifier

только Manager лишнее

ClassLoader назови мне по-другому

только Manager лишнее

то есть PasswordVerifier это норм, да?

а что с ним не так?

и что он делает?

просто считает хеш и сравнивает с юзеровым?

и что он делает?

верифаит пароль очевидно)

или проверяет можно ли взять такой пароль?

если проверка на можно ли взять пароль - то вполне годно

если нет - то место в методе юзера

задача к ООП относится?

верифаит пароль очевидно)

ну так, проблемы то какие?

ну так, проблемы то какие?

есть очень большая вероятность пропущенной концепции

в данном случае концепция пароля или что-то связанное с доступом

не понял поинта

в данном случае концепция пароля или что-то связанное с доступом

Предмет какбы Ооп

в данном случае концепция пароля или что-то связанное с доступом

давай более конкретно

вот взять https://github.com/voxsim/password-verifier-kata

в понятии этой каты верификация пароля это как раз валидация

почему бы не проводить эту валидацию в конструкторе класса Password?)

отлично

теперь добавим верификацию что пароль не должен быть таким как предыдущие

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

первая проверка ложится в User а вторая проверка - тут есть варианты. Откуда твой PasswordVerifier узнает словарь паролей?

это уже его детали, клиенту пофиг

ну тогда будет какой-то CommonPasswordDictionary который можно даже передать в статический метод-фабрику пароля

>первая проверка ложится в User а вторая проверка - тут есть варианты ты еще предлагаешь в юзера ложить правила валидации?

да, это ж история паролей юзера

а как же то что юзер должен быть всегда в валидном состоянии?

ну то есть это совершенно разные рулы

а как же то что юзер должен быть всегда в валидном состоянии?

не вижу противоречий

public function changePassword(Password $oldPassword, Password $newPassword) { // проверяем по истории паролей пользователя и кидаем ошибку чуть что }

при создании юзера у нас история как бы пустая и там подобный рул не имеет смысла

как это будет выглядеть? $user->changePassword($password), а внутри ты делаешь все валидации?

как это будет выглядеть? $user->changePassword($password), а внутри ты делаешь все валидации?

я думаю за валидации вроде проверка по словарю - за это отвечает фабрика паролей. Что-то типа

password should be larger than 8 chars password should not be null password should have one uppercase letter at least password should have one lowercase letter at least password should have one number at least

еще вот эти правила нужны, и в случае чего показать их клиенту

если он нарушил чего

давай разберемся, тебя валидатор строк интересует ддя UI или ты хочешь бизнес правила установить?*

а, есть еще вариант

вместо исключений юзать доменные ивенты)

InvalidPasswordUsed

password should be larger than 8 chars password should not be null password should have one uppercase letter at least password should have one lowercase letter at least password should have one number at least

мне нужны эти правила, + проверка по словарю, и проверка не использовался ли пароль ранее

ну либо ты будешь смешивать проверку бизнес правил и UI kогику (отображение ошибок валидации)

мне нужны эти правила, + проверка по словарю, и проверка не использовался ли пароль ранее

твоя проблема что ты воспринимаешь этот сэт рулов как что-то одно, а по факту пароль может спокойно существовать и без проверки по истории паролей юзера, ведь только у юзера есть эта история

я хочу получить ValidationViolations, а как его буду юзать это другой вопрос

я хочу получить ValidationViolations, а как его буду юзать это другой вопрос

это относится целиком и полностью к UI layer и там юзай валидатор

честно говоря пароль юзера... разве это домен?

честно говоря пароль юзера... разве это домен?

если ты делаешь сервис типа auth0 - то почему бы и да?)

твоя проблема что ты воспринимаешь этот сэт рулов как что-то одно, а по факту пароль может спокойно существовать и без проверки по истории паролей юзера, ведь только у юзера есть эта история

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

список правил которые должны соблюдаться и ValidationViolations, если что-то нарушено

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

тебе короч валидатор нужен для UI-ки а не ооп

без разницы, это могут быть просто логи

это уже не должно касаться задачи

ты сам усложняешь себе жизнь за счет того что все проверки должны быть проведены разом. То есть мы по любому должны иметь дело с невалидным стэйтом. А это значит что мы уходим из домена и переходим в страшный процедурный мир инфраструктуры

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

ты опять от темы уходишь

я говорю что мне без разницы где ты валидировать будешь первичный пароль

ты опять от темы уходишь

не ухожу, я уже говорил что не везде ООП нужен. Есть вещи для которых нужны функции просто

можешь хоть в каждом слое по одному рулу проверять

теперь возвращаемся к PasswordVerifier

можешь хоть в каждом слое по одному рулу проверять

так

стой

нет

погоди

список правил которые должны соблюдаться и ValidationViolations, если что-то нарушено

1. если у нас нарушены правила относящиеся к самому паролю мы априори не можем проверить ни наличие пароля в словаре ни то что у юзера оно было. Так? 2. Если пароль содержится в словаре, то его не может быть в истории юзеров 3. Если пароль валидный сам по себе - остается только один рул - проверка по истории юзера

1. если у нас нарушены правила относящиеся к самому паролю мы априори не можем проверить ни наличие пароля в словаре ни то что у юзера оно было. Так? 2. Если пароль содержится в словаре, то его не может быть в истории юзеров 3. Если пароль валидный сам по себе - остается только один рул - проверка по истории юзера

верно

>2. Если пароль содержится в словаре, то его не может быть в истории юзеров может быть исключение, если словарь обновляется

User::builder() ->withPassword(Password::fromString($password, $commonPasswordDictionary); $user->changePassword(Password::fromString($oldPassword), Password::fromString($oldPassword, $commonPasswordDictionary))

>2. Если пароль содержится в словаре, то его не может быть в истории юзеров может быть исключение, если словарь обновляется

то есть проблемы будут только если мы убираем какой-то пароль из списка исключений

или добавляем

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

да и если есть - снова уже быть не может

старая соль + новый пароль =(возможность) старый хеш

ну и опять же что делать с чуваками которые при обновлении твоих правил по паролям оказывается юзают невалидный?)

ну и опять же что делать с чуваками которые при обновлении твоих правил по паролям оказывается юзают невалидный?)

забить

старая соль + новый пароль =(возможность) старый хеш

зачем юзать старую соль?

это ж снижает секьюрность

хотя можно прислать им письмо что чуваки, ваш пароль есть в базе, которую слили)

зачем юзать старую соль?

она ж всегда лежит рядом с хешем

хотя можно прислать им письмо что чуваки, ваш пароль есть в базе, которую слили)

ты об этом можешь узнать только в момент ввода пароля (логин например)

она ж всегда лежит рядом с хешем

и мне ее генерит password_hash который эту самую соль сам генерит и конкатенирует вместе с хэшем

а как ты проверишь не юзался ли пароль, если не использовать старую соль?

и я не хочу что бы логика хэширования просачивалась в моего юзера

а как ты проверишь не юзался ли пароль, если не использовать старую соль?

у тебя при смене пароля есть пароль в открытом виде

делаешь просто password_verify для всех этих штук