У нас на остановках постоянно маршруткам зигуют

Рим пал, центурион

Чот сейчас призадумался и понял, что не могу понять, как лучше это сделать и почему:

Есть у нас какой-то дата сурс\репозиторий, в нём нужна возможность сохранять новые сущности. Например, юзеров. У юзеров определённая моделька, пусть

 data class User(val id: Long, val name: String)

И вот я думаю, как лучше создавать их? Передавая в метод создания уже готовый объект User и игнорить поле id (потому что оно будет заполняться потом при сохранении) или же передавать аргументами нужные для создания поля и уже на стороне дата сорса работать с ними?

 data class User(val id: Long, val name: String)

пильнуть отдельную модельку CreateUser?

Модель на запись сделай, или дырок понаделай

Одно из стандартных названий https://reasonablypolymorphic.com/blog/higher-kinded-data/

Короче делаешь

final case class GMessage[F[_]](
   id: F[Id]
  foo: Foo,
  bar: F[Bar],
  baz: Baz
)


object GMessage{
  type Message  = GMessage[Id]
  type MessageInput = GMessage[Option]

  implicit val inputDecoder: Decoder[MessageInput] = deriveDecoder
 }

Второе шутка, лучше просто модель на запись

Думал об этом варианте, но только чтобы игнорировать id создавать отдельную модельку — стрёмно как-то.

Намана

в противном случае получается богомерзкий паттерн, которым пользуются всякие ОРМы с Entity, у которых поля опционально пустые, а никого и не парит

Не знаю, как другие к этому относятся, имха, это пиздос

Это, конечно, пиздец, спору нет.
Но так будет уже две модельки за которыми следить и у которых различие на одно поле.

Выходит, шо то гавно, шо это

нет, получается CQS

А что за дырки?

Так я кинул пример же

Да это хуйня забей

Норм работает на практике, позволяет кучу кода сэкономить в сложных случаях. Но в котлине не сработает, само собой.