Datenklasse in Kotlin erweitern

Datenklassen scheinen der Ersatz für die altmodischen POJOs in Java zu sein. Es ist durchaus zu erwarten, dass diese Klassen eine Vererbung ermöglichen, aber ich sehe keine bequeme Möglichkeit, eine Datenklasse zu erweitern. Was ich brauche ist so etwas:

open data class Resource (var id: Long = 0, var location: String = "")
data class Book (var isbn: String) : Resource()

Der obige Code schlägt aufgrund von component1()Methodenkonflikten fehl . Das Belassen von dataAnmerkungen nur in einer der Klassen erledigt die Arbeit ebenfalls nicht.

Vielleicht gibt es eine andere Redewendung, um Datenklassen zu erweitern?

UPD: Ich kann nur untergeordnete untergeordnete Klassen mit dataAnmerkungen versehen, aber mit Anmerkungen werden nur Eigenschaften behandelt, die im Konstruktor deklariert sind. Das heißt, ich müsste alle Eigenschaften der Eltern deklarieren openund überschreiben, was hässlich ist:

open class Resource (open var id: Long = 0, open var location: String = "")
data class Book (
    override var id: Long = 0,
    override var location: String = "",
    var isbn: String
) : Resource()

Die Wahrheit ist: Datenklassen spielen mit Vererbung nicht so gut. Wir erwägen, die Vererbung von Datenklassen zu verbieten oder stark einzuschränken. Es ist beispielsweise bekannt, dass es keine Möglichkeit gibt, nicht equals()abstrakte Klassen in einer Hierarchie korrekt zu implementieren .

Alles, was ich anbieten kann: Verwenden Sie keine Vererbung mit Datenklassen.

Deklarieren Sie Eigenschaften in der Oberklasse außerhalb des Konstruktors als abstrakt und überschreiben Sie sie in der Unterklasse.

abstract class Resource {
    abstract var id: Long
    abstract var location: String
}

data class Book (
    override var id: Long = 0,
    override var location: String = "",
    var isbn: String
) : Resource()

Die obige Lösung unter Verwendung einer abstrakten Klasse generiert tatsächlich eine entsprechende Klasse und lässt die Datenklasse daraus erweitern.

Wenn Sie keine abstrakte Klasse bevorzugen, wie wäre es dann mit einer Schnittstelle ?

Die Schnittstelle in Kotlin kann Eigenschaften haben, wie in diesem Artikel gezeigt .

interface History {
    val date: LocalDateTime
    val name: String
    val value: Int
}

data class FixedHistory(override val date: LocalDateTime,
                        override val name: String,
                        override val value: Int,
                        val fixedEvent: String) : History

Ich war gespannt, wie Kotlin das kompiliert. Hier ist äquivalenter Java-Code (generiert mit der Intellij-Funktion [Kotlin-Bytecode]):

public interface History {
   @NotNull
   LocalDateTime getDate();

   @NotNull
   String getName();

   int getValue();
}

public final class FixedHistory implements History {
   @NotNull
   private final LocalDateTime date;
   @NotNull
   private final String name;
   private int value;
   @NotNull
   private final String fixedEvent;

   // Boring getters/setters as usual..
   // copy(), toString(), equals(), hashCode(), ...
}

Wie Sie sehen, funktioniert es genau wie eine normale Datenklasse!

@ Željko Trogrlić Antwort ist richtig. Aber wir müssen die gleichen Felder wie in einer abstrakten Klasse wiederholen.

Auch wenn wir abstrakte Unterklassen innerhalb der abstrakten Klasse haben, können wir in einer Datenklasse keine Felder aus diesen abstrakten Unterklassen erweitern. Wir sollten zuerst eine Datenunterklasse erstellen und dann Felder definieren.

abstract class AbstractClass {
    abstract val code: Int
    abstract val url: String?
    abstract val errors: Errors?

    abstract class Errors {
        abstract val messages: List<String>?
    }
}



data class History(
    val data: String?,

    override val code: Int,
    override val url: String?,
    // Do not extend from AbstractClass.Errors here, but Kotlin allows it.
    override val errors: Errors?
) : AbstractClass() {

    // Extend a data class here, then you can use it for 'errors' field.
    data class Errors(
        override val messages: List<String>?
    ) : AbstractClass.Errors()
}

Kotlin Traits können helfen.

interface IBase {
    val prop:String
}

interface IDerived : IBase {
    val derived_prop:String
}

Datenklassen

data class Base(override val prop:String) : IBase

data class Derived(override val derived_prop:String,
                   private val base:IBase) :  IDerived, IBase by base

Beispielnutzung

val b = Base("base")
val d = Derived("derived", b)

print(d.prop) //prints "base", accessing base class property
print(d.derived_prop) //prints "derived"

Dieser Ansatz kann auch eine Problemumgehung für Vererbungsprobleme mit @Parcelize sein

@Parcelize 
data class Base(override val prop:Any) : IBase, Parcelable

@Parcelize // works fine
data class Derived(override val derived_prop:Any,
                   private val base:IBase) : IBase by base, IDerived, Parcelable

Sie können eine Datenklasse von einer Nicht-Datenklasse erben. Das Erben einer Datenklasse von einer anderen Datenklasse ist nicht zulässig, da vom Compiler generierte Datenklassenmethoden im Falle einer Vererbung nicht konsistent und intuitiv funktionieren können.

Während die equals()korrekte Implementierung in einer Hierarchie in der Tat eine ziemliche Herausforderung darstellt, wäre es dennoch hilfreich, die Vererbung anderer Methoden zu unterstützen, zum Beispiel : toString().

Um etwas konkreter zu sein, nehmen wir an, wir haben das folgende Konstrukt (offensichtlich funktioniert es nicht, weil toString()es nicht vererbt wird, aber wäre es nicht schön, wenn es so wäre?):

abstract class ResourceId(open val basePath: BasePath, open val id: Id) {

    // non of the subtypes inherit this... unfortunately...
    override fun toString(): String = "/${basePath.value}/${id.value}"
}

data class UserResourceId(override val id: UserId) : ResourceId(UserBasePath, id)

data class LocationResourceId(override val id: LocationId) : ResourceId(LocationBasePath, id)

Unter der Annahme , unseren Userund LocationOrganisationen ihren entsprechenden Ressourcen - IDs zurückgeben ( UserResourceIdund LocationResourceIdjeweils), Aufruf toString()auf jedem ResourceIdin einer recht netten kleinen Darstellung führen könnten , die für alle Subtypen im Allgemeinen gilt: /users/4587, /locations/23usw. Leider, denn nicht die zu verdrängte geerbte Subtypen toString()Verfahren aus dem abstrakte Basis ResourceId, Aufruf führt toString()tatsächlich zu einer weniger hübschen Darstellung : <UserResourceId(id=UserId(value=4587))>,<LocationResourceId(id=LocationId(value=23))>

Es gibt andere Möglichkeiten, das oben Genannte zu modellieren, aber diese Möglichkeiten zwingen uns entweder dazu, Nicht-Datenklassen zu verwenden (wobei viele Vorteile von Datenklassen fehlen), oder wir kopieren / wiederholen die toString()Implementierung in allen unseren Datenklassen (keine Vererbung).

Sie können eine Datenklasse von einer Nicht-Datenklasse erben.

Basisklasse

open class BaseEntity (

@ColumnInfo(name = "name") var name: String? = null,
@ColumnInfo(name = "description") var description: String? = null,
// ...
)

Kinderklasse

@Entity(tableName = "items", indices = [Index(value = ["item_id"])])
data class CustomEntity(

    @PrimaryKey
    @ColumnInfo(name = "id") var id: Long? = null,
    @ColumnInfo(name = "item_id") var itemId: Long = 0,
    @ColumnInfo(name = "item_color") var color: Int? = null

) : BaseEntity()

Es funktionierte.