Antwort.

In Kotlin wird der Modifikator const val nur für Compile-Time-Konstanten auf Top-Level (Dateiebene) oder innerhalb von Objekten (object) und Begleitobjekten verwendet. Eigenschaften, die innerhalb von Klassen als val deklariert sind, werden zu gewöhnlichen finalen Eigenschaften ohne statische Initialisierung. Eine wichtige Eigenschaft: const val kann nicht vererbt werden, während val überschrieben werden kann (wenn es erlaubt ist).

Konstanten (const val) können nicht abstrakt sein, da sie zur Kompilierungszeit einen Wert haben müssen. Gewöhnliche val erlauben es, das Konstante-Muster in Hierarchien durch offene Eigenschaften zu implementieren, jedoch sind sie zur Laufzeit über Getter verfügbar, was sich von der Kompilierung in Java unterscheidet.

Beispiel:

open class Base {
    open val info: String = "base"
}
class Child : Base() {
    override val info = "child"
}

object Constants {
    const val APPLICATION_NAME = "MyApp"
}

Trickfrage.

Kann man const val in einem Interface oder einer abstrakten Klasse deklarieren und dann überschreiben/vererben?

Antwort mit Beispiel:

Nein. In Kotlin kann man const val nicht innerhalb eines Interfaces oder einer abstrakten Klasse deklarieren - dies ist nur auf der Ebene eines Objekts (object) und auf Top-Level zulässig. Entsprechende statische final Variablen, die für die Vererbung verfügbar sind, gibt es nicht.

interface Foo {
    // const val X = "constant" // Kompilierungsfehler: const 'val' sind nur auf Top-Level, in Objekten oder in Begleitobjekten erlaubt
}

Beispiele für echte Fehler aufgrund mangelndes Verständnisses der Feinheiten des Themas.

---

Geschichte

Das Team versuchte, String-Konstanten durch Vererbung von Interfaces in mehreren Android-Modulen wiederzuverwenden, indem es diese als const val deklarierte - es gab einen Kompilierungsfehler und sie mussten die Konstanten auf Top-Level verschieben, was die Kapselung verschlechterte.

---

Geschichte

Im Projekt wurden alle Java static final Felder in Kotlin val-Felder in offenen Klassen umgewandelt, in der Erwartung eines ähnlichen Verhaltens (compile-time const), jedoch wurden sie zu gewöhnlichen Eigenschaften mit Getter. Infolgedessen verlängerte sich die Zugriffszeit, was sich negativ auf die heißen Pfade (hot path) der Mikrodienstanwendung auswirkte.

---

Geschichte

Bei der Portierung von Java-Klassen von Konstantencontainern nach Kotlin machten die Entwickler Konstanten innerhalb des Begleitobjekts, stießen jedoch auf ein Zugriffsproblem aus dem Java-Code: Die Konstanten waren als Felder des Begleiters sichtbar, nicht der Klasse, was zu Verwirrung im API und zusätzlichen Interoperabilitätsfehlern führte.