14. Функции-расширения используются только там, где нет возможности добавить классу нужную функцию
Функции-расширения - это прекрасная фича Котлина, которую иногда начинают использовать странным образом:
data class ItemRequest(
val code: String?,
val name: String?,
)
fun ItemRequest.toEntity() = ItemEntity(
code = this.code,
name = this.name,
)
В примере приведён код, который лежит в одном и том же файле ItemRequest.kt.
Зачем делать преобразование одного объекта в другой через статическую функцию - для меня большая загадка. В общем, не делайте так.
Правильнее будет сдеать то же самое через функцию-член класса:
data class ItemRequest(
val code: String?,
val name: String?,
) {
fun toEntity() = ItemEntity(
code = code,
name = name,
)
}
15. ВСЕ таблицы в реляционной базе данных имеют колонку ID с типом bigserial primary key.
Этот тип характерен для PostgreSQL. Для других реляционных баз данных могут использоваться схожие типы (генерируемые базой данных biginteger, long и т.п.).
Почему именно так строго?
Чтобы это прочувствовать, предлагаю читателю в качестве самостоятльного упражнения взять любую реляционную базу данных с 2-3 связанными друг с другом внешними ключами табличками и попробовать в этих табличках заменить все id типа biginteger на id типа varchar или - ещё "интереснее" - на составные id, в которые будут входить по 2-3 колонки из каждой таблицы.
Следующим шагом нужно будет востановить между таблицами связи по внешним ключам.
Затем - написать код, который будет с такими таблицами работать (через ORM или без него, не важно).
После - реализовать в коде key-set пагинацию.
И если до этого момента вам будет ещё непонятно, насколько глубоко в Ада вы погрузились, включите логическую репликацию базы данных.
Если вы были достаточно умны, чтобы дойти до этого места и достаточно отважны, чтобы не повернуть обратно, а до конца испытать все боль и унижение от происходящего, то в момент включения логической репликации вы поймёте, что преодолевали и костылили вы напрасно и что надо было сразу надавать себе по рукам, дропнуть составные id и добавить нормальные, с типом biginteger.
Я видел реляционные базы данных, в которых использовались составные id и вроде бы казалось, что они там к месту. Но я не видел ни одной базы данных, где нельзя было бы обойтись без них. И я не слышал ни одного вразумительного ответа на вопрос, почему в этом месте НЕЛЬЗЯ было вместо составного id использовать id типа biginteger.