Почему в яве хэшированием пароля пользовалетя занимается сервис?

Question

[Антон Иванов]

Всем привет.

Разбираюсь с явой по примерам с сайта baeldung.com.
Возник вопрос по вот этому уроку: https://www.baeldung.com/spring-security-registrat...

Почему хэшированием пароля пользователя занимается сервис, который создает пользователя?
Ведь это оставляет возможность установить пользователю plain-text пароль.

Comments

[Сергей Горностаев]

Правильнее переформулировать вопрос так "Почему у Eugen Paraschiv хэшированием пароля пользовалетя занимается сервис?" И задать его самому автору этого кода.

[Антон Иванов]

Сергей Горностаев, скорее всего Вы правы. Тогда спрошу по другому. Есть ли какой-то минус в том, что я перенесу хеширование пароля в класс модели пользователя? Не привнесет ли это каких-то новых возможных багов или не является это каким-нибудь "не феншуйным" подходом? :)

[Максим Федоров]

Антон Иванов,
можете перенести

вообще сеттеры и геттеры нужно выкинуть, анемия — зло

[Антон Иванов]

Максим Федоров, есть что почитать на тему, почему сеттеры и геттеры - зло? кроме https://habr.com/ru/post/469323/

[Максим Федоров]

Антон Иванов, ой, ну вы же в Java, у вас эта тема очень развита, Фаулер в придачу докидывает доводов вместе с Верноном

:)

Вы же неспроста почуяли, что все что угодно в разных вариантах можно в сущность закинуть... :) и что инкапсуляция и есть, но по факту ее нет

[Антон Иванов]

Максим Федоров, Я в Java три дня ) Ок, почитаю, спасибо

[Максим Федоров]

Антон Иванов,
краткую суть вы можете увидеть в моей статье

• если коротко — сеттеры/геттеры нарушают инкапсуляцию. Что это означает — сущность может находить в невалидных состояниях, вся логика снаружи (когда данные внутри) — то есть возврат в процедурщину, когда данные отдельно, методы отдельно...
  
• течет логика, а самое сложное в средних/огромных проектах — размываются границы слоев и ответственности
  
• тестирование превращается в боль. тк всегда можно "зассетить" и прилетели, тесты не покрыли такой кейс :) сама реализация тестов становится болью — всегда тащить сущность с собой не удобно, прилетели
  
• низкая внутренняя связанность и большая внешняя — про границы указал уже, это и закон Деметры нарушает, и вообще боль по жизни
  

Моя статья говорит о банальном — банальный принцип ООП просто растоптан, тк уже не ООП, а процедурщина в ООП-обертке, тогда как честнее было бы процедурный язык взять

[Максим Федоров]

Антон Иванов, гуглите:

• Rich Model vs Anemic Model
  
• пробелма сеттеров и геттеров
  
• high cohesion/ low coupling, закон Деметры
  
• семантическая инкапсуляция
  

[Антон Иванов]

Максим Федоров, спасибо, буду читать

[Денис Загаевский]

Максим Федоров, сущность должна быть построена так, что любое её состояние валидно.
Сеттеры зло и должны не существовать. Иммутабельность наше всё. Логика должна быть в классах логики, какой-то User не должен её иметь вообще.

[Максим Федоров]

Денис Загаевский,

Логика должна быть в классах логики, какой-то User не должен её иметь вообще.

что значит какой-то?

Иммутабельность наше всё.

Всеми руками ЗА!

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

Выше я сделал упор на это :) зачем мне это писать? :)

Answer 1

[Dmitry Roo]

Потому что ничего не мешает сделать вам проверку сложности пароля на фронте. И, согласно принципу single-responsibility, это не сервиса дело - какие там требования к сложности пароля. Кроме того, таким проверкам как раз на фронте и место. Нет никакого смысла отправлять пароль куда-то на бэк, чтобы там выяснилось, что пароль не соответствует требованиям.

Comments

[Антон Иванов]

Не очень понял, как это отвечает на мой вопрос.

Смысл моего вопросы был, что если хешированием пароля занимается сервис, то у других сущностей остается возможность создать пользователя с plain-text паролем.