можно просто пренебречь проверками на null: если возникнет NPE, значит, с бизнес-логикой в любом случае что-то не так
Вы это серьёзно!? NPE - это в любом случае ошибка программиста, не надо сваливать на бизнес-логику. Так вот у сервисов пятисотки то и летят с таким подходом
> вручную написать hashCode и equals, а так же toString, правильно?
Нет. Примерно вот так:
@Table("MESSAGES")
data class Message(
val content: String,
val contentType: ContentType,
val sent: Instant,
val username: String,
val userAvatarImageLink: String,
@Id var id: String? = null)
или это не по фен-шую? Не все требования выполняются, да, наверное в каких-то ситуациях надо будет писать свой equals и hashCode.
Наверное я упускаю какой то контекст. А апелляция к чему? К тому, что дата классы не могут быть использованы в качестве Entity? Вот прям только что использовал дата классы для того чтобы работать со Spring Data — ничто не помешало.
Просто один и тот же разраб тупо сделал DTO на Java, потом на Kotlin.
Мы же знаем, что у всего есть цена. Нужно учитывать контекст задачи. Вот например можно почитать, во что это выливается когда есть дополнительные требования.
Ну просто это как раз и интересно. Расскажите про своё тестирование и результаты. Иначе заявления что «объективно измерили» звучат конечно же воспринимаются читателями как пятничный наброс.
Зависит, на сколько развесистую абстракцию вы себе придумаете. Если не вводить свои абстракции, то достаточно легко. Наверное, даже можно было бы автоматически, т.к. даже если перезаписать настройки то они не будут отличаться от того, что было бы написано напрямую в коде.
Автоматически применить патч можно только переписав полностью настройки. Ведь в коде могут быть заведены какие-нибудь свои абстракции про которые ТС не знает. ТС работает с внутренней моделью проекта и патч генерируется относительно этой модели.
UUID на самом деле необязателен. Если UUID не задать, то он генерируется из обычного id, который получается из имени объекта.
Другое дело, что иногда может придти мысль «порефакторить» конфигурации и переименовать объект. А так как истолия сборок связана через этот id, то при переименовании объекта история вдруг может оказаться несвязанной с новом id. Но этого можно избежать — либо задать таки UUID, либо связать историю через UI.
К сожалению, в статье нет хорошего конкретного обоснования, зачем это нужно.
Если в какой-то библиотеке баг, то надо не преобразовывать байткод, а исправлять эту ошибку в библиотеке.
А как можно использовать Javassist, в интернетах информации пруд пруди.
Вы это серьёзно!? NPE - это в любом случае ошибка программиста, не надо сваливать на бизнес-логику. Так вот у сервисов пятисотки то и летят с таким подходом
У экологов память какая-то короткая. Такая жара в Эстонии переодически все таки случается. Просто очень редко
Спасибо за статью! :)
Используется со Spring Data. JPA — так сразу и надо было сказать :)
Для JPA дата классы конечно же не очень хорошо подходят.
Нет. Примерно вот так:
или это не по фен-шую? Не все требования выполняются, да, наверное в каких-то ситуациях надо будет писать свой equals и hashCode.
Интересно. А можно проблему с Entity описать?
Мы же знаем, что у всего есть цена. Нужно учитывать контекст задачи. Вот например можно почитать, во что это выливается когда есть дополнительные требования.
Можно узнать, есть ли где то результаты замеров? :)
Другое дело, что иногда может придти мысль «порефакторить» конфигурации и переименовать объект. А так как истолия сборок связана через этот id, то при переименовании объекта история вдруг может оказаться несвязанной с новом id. Но этого можно избежать — либо задать таки UUID, либо связать историю через UI.