español - Extendiendo la clase de datos de una clase sellada en Kotlin

kotlin vs java

Question

Tengo un conjunto de clases de datos que comparten algunos campos comunes, así que idealmente me gustaría declararlos en un supertipo (Mensaje en este ejemplo), y poder escribir funciones que operen en el supertipo si necesitan acceso a estos campos (messageId en este ejemplo).

fun operate(m: Message) {
  use(m.messageId)
}

Intenté lograr esto extendiendo mis clases de datos de una clase sellada.

Las clases de datos pueden extender las clases selladas, pero no estoy seguro de cómo / si pueden aceptar los argumentos requeridos por la clase sellada "supertipo".

1. Extender una clase regular de una clase sellada compila bien.

   sealed class Message(val messageId: String)
   
   class Track(val event: String, messageId: String): Message(messageId)

2. Sin embargo, cambiarlo a una clase de datos no se compila ("El constructor primario de la clase de datos debe tener solo parámetros de propiedad (val / var)").

   sealed class Message(val messageId: String)
   
   data class Track(val event: String, messageId: String): Message(messageId)

3. La declaración del parámetro como una propiedad tampoco se compila ("" messageId ''oculta el miembro del supertipo'' Message ''y necesita'' modificador '''').

   sealed class Message(val messageId: String)
   
   data class Track(val event: String, val messageId: String): Message(messageId)

4. Abrir la propiedad de supertipo y sobrescribirla en cada una de las clases base se compila bien:

   sealed class Message(open val messageId: String)
   
   data class Track(val event: String, override val messageId: String): Message(messageId)

Idealmente, me gustaría algo cercano a la Opción 2: me permite combinar lo mejor de ambos mundos.

De lo contrario, parece que mis opciones están manejando mi propia funcionalidad de clase de datos (copiar, código de hash, etc.) con la opción 1, o vivir con un compromiso al abrir las propiedades de supertipo con la opción 4.

Answer 1

Las opciones 3 y 4 darían como resultado que la clase sostuviera messageId dos veces. Una vez en la nueva clase y una vez en su superclase.

La solución es declarar pero no definir la variable en la superclase:

sealed class Message {
    abstract val messageId: String
}

data class Track(val event: String, override val messageId: String): Message()

Esto hará que messageId esté disponible en Message , pero delega el almacenamiento a lo que lo implemente.