Antwort.

Data object ist ein neuer Typ von Deklarationen in Kotlin (seit Version 1.9), der die Eigenschaften eines Singleton-Objekts und einer data class vereint. Es ist für Fälle gedacht, in denen man nur eine Instanz eines Objekts und automatisch generierte Methoden wie equals, hashCode, toString (wie bei data class) haben möchte.

Hintergrund

Früher musste man für die Speicherung von einzigartigen Entitäten mit automatisch generierten Methoden toString() und equals() ein object mit manuellen Implementierungen schreiben oder kompromissbereit eine data class mit einem einzigen Objekt (und nicht mehreren Instanzen) verwenden.

Problem

Singleton-Objekte (object) haben keine automatisch generierten equals, hashCode, toString, während data class mehrere Instanzen unterstützt, was nicht für erschöpfende enum-ähnliche Modelle geeignet ist.

Lösung

Mit dem Auftreten von data object werden beide Aufgaben elegant gelöst:

Die Klasse kann nur eine Instanz sein (singleton).
Der Compiler generiert die erforderlichen Multimethoden.

Codebeispiel:

data object LoadingState

data object NoData

println(LoadingState == LoadingState) // true
println(LoadingState.toString()) // LoadingState

Wichtige Merkmale:

Immer singleton — es kann keine zweite Instanz erstellt werden.
Der Compiler fügt Methoden wie equals, hashCode, toString hinzu, wie bei data class.
Besonders bequem in Kombination mit sealed interface zur Modellierung von Zuständen anzuwenden.

Fangfragen.

Was unterscheidet data object von einem normalen object?

Nur data object erhält die automatische Generierung der Methoden equals, hashCode, toString auf Compiler-Ebene; normales object verwendet Implementierungen aus Any (referentielle Gleichheit, triviales toString).

Kann man ein data object mit Konstruktorparametern erstellen?

Nein, ein data object kann keine Konstruktoren mit Parametern haben. Es hat immer keine Parameter, da es nur eine Instanz gibt.

Kann man ein data object erben?

Ja, data object kann Interfaces implementieren, einschließlich sealed interface, und Teil von Zustandshierarchien sein.

Beispiel:

sealed interface Result

data object Success : Result

data object Failure : Result

Typische Fehler und Anti-Pattern

Versuch, Konstruktorfelder in data object hinzuzufügen (das ist nicht erlaubt).
Verwendung von data class, wo nur eine Instanz erwartet wird.

Beispiel aus dem Leben

Negativer Fall

Ein Entwickler modelliert „keine Daten“ als object NoData, vergleicht dann mit equals() mit einem externen Objekt und erhält ein unerwartetes Ergebnis (referentielle Überprüfung, nicht inhaltlich).

Vorteile:

Einfachheit der Deklaration.

Nachteile:

Unangemessenes Verhalten bei equals/toString.

Positiver Fall

Ein data object wird für Lade-Status verwendet, Gleichheit und Ausgabe erfolgen nach den erwarteten data class-Regeln. Die Modellschicht nutzt zuverlässig das Muster-Matching nach Zuständen.