Можно все программирование свести к одной табличке. Но глубокого понимания причин того или иного решения это не даст. Этим скорее всего и отличаются кодеры от программистов.
Это не проблема в глобальном смысле, пока ты не начинаешь бороться с чистотой и производительностью кода. Странно то, что многие, в том числе из перечисленных в конце статей, не до конца осознают из-за чего это все происходит.
В целом наверно Ваше мнение поддерживает большинство. Но я так не хочу)
Наверно надо начинать материться в комментариях чтобы тебя не считали ллм) Теперь вся элементарная вежливость и знание знаков препинания и правил русского языка будет относить тебя к ним...
Вы абсолютно правы, JPA-сущности (@Entity) требуют конструктор по умолчанию. Но это другой тип класса с другим жизненным циклом, управляемым Hibernate, а не Spring DI. Мы говорим о сервисах, компонентах и репозиториях (@Service, @Component, @Repository), где вся логика работы строится на зависимостях, и их целостность критична.
Так это и проходит красной нитью через весь текст)
"К моменту завершения конструктора все инварианты должны быть выполнены. Объект, вышедший из конструктора, обязан быть целостным (consistent) и готовым к работе."
Я подумаю насчет статьи. А пока скажу, чтоsynchronized напрямую манипулирует Mark Word объекта для реализации легковесных блокировок, аReentrantLock вроде использунт механизм AQS, который практически не влияет на Mark Word самого защищаемого объекта, а иногда даже не требует отдельного объекта для блокировки
Ну на поверхности или нет, но очень часто вижу, что многие этого вовсе не знали)
Аргументов в пользу field injection кроме как удобства нет)
Ничего не понятно, но очень интересно...
Чтобы было меньше сомнений. Так пишешь-пишешь пол дня, а потом ты - ллм)
Можно все программирование свести к одной табличке. Но глубокого понимания причин того или иного решения это не даст. Этим скорее всего и отличаются кодеры от программистов.
Это не проблема в глобальном смысле, пока ты не начинаешь бороться с чистотой и производительностью кода. Странно то, что многие, в том числе из перечисленных в конце статей, не до конца осознают из-за чего это все происходит.
В целом наверно Ваше мнение поддерживает большинство. Но я так не хочу)
Наверно надо начинать материться в комментариях чтобы тебя не считали ллм) Теперь вся элементарная вежливость и знание знаков препинания и правил русского языка будет относить тебя к ним...
Вы абсолютно правы, JPA-сущности (
@Entity) требуют конструктор по умолчанию. Но это другой тип класса с другим жизненным циклом, управляемым Hibernate, а не Spring DI. Мы говорим о сервисах, компонентах и репозиториях (@Service,@Component,@Repository), где вся логика работы строится на зависимостях, и их целостность критична.Так это и проходит красной нитью через весь текст)
"К моменту завершения конструктора все инварианты должны быть выполнены. Объект, вышедший из конструктора, обязан быть целостным (consistent) и готовым к работе."
Я бы вам порекомендовал в качестве дто использовать не объекты из OpenApi, а из JOOQ. Там и record'ы есть для спокойной передачи данных
Спасибо за статью, позволю себе несколько замечаний по коду (так сказать ревью):
Mono<@NonNullVoid>- крайне спорно и по-моему бессмысленнов UserServiceотсутствует обработка ошибок. Вообще.В целом подозреваю, что все это сделано из-за быстроты и генерации части кода OpenAPI Generator. Советую поставить openApiNullable: "true".
Есть непонятный мне конфликт:
useOptional: "true", //Использовать Optional
openApiNullable: "false", // Но ничего не может быть null?!
В тесте вообще не пойму откуда
User user =newUser();Ведь если это DTO из OpenAPI то как минимум в коде вижу
UpdateUser.Да и чтоUpdateUserделает в createUser методе?)В github вообще не нашел папки по пути ru.maximserver.vmuserservice.model указанные в сервисном слое.
Очень много загадочного в проекте на мой взгляд))
Прошу простить, что надушнил, но кто-то(например я) захочет что-то изучить по вашему коду и столкнется с множеством проблем.
Спасибо за мнение!
Я подумаю насчет статьи. А пока скажу, что
synchronizedнапрямую манипулирует Mark Word объекта для реализации легковесных блокировок, аReentrantLockвроде использунт механизм AQS, который практически не влияет на Mark Word самого защищаемого объекта, а иногда даже не требует отдельного объекта для блокировки