Antwort.

Geschichte der Frage:

Kotlin vereint die besten Seiten von Java und das funktionale Erbe der JVM. Normale Klassen werden als Standardstrukturen deklariert, abstrakte Klassen ermöglichen die Erstellung von unterdefinierten Vorlagen mit Standardimplementierung, und Schnittstellen unterstützen die mehrfache Vererbung von Verhalten ohne Zustand.

Problem:

Die richtige Wahl zwischen Klasse, abstrakter Klasse und Schnittstelle bestimmt die Architektur der Anwendung, die Granularität des Codes und dessen Erweiterbarkeit. Falsche Vererbung führt zu Schwierigkeiten bei Tests und zukünftigen Änderungen.

Lösung:

In Kotlin:

Normale Klasse: definiert Struktur und Verhalten. Kann vererbt werden, wenn als open deklariert.
Abstrakte Klasse: kann nicht direkt instanziiert werden. Kann Implementierungen und/oder abstrakte (ohne Körper) Methoden enthalten.
Schnittstelle: implizit offen, implementiert Verträge, erlaubt die Implementierung von Methoden, kann aber keinen Zustand speichern (nur Eigenschaften ohne backing field).

Beispielcode:

interface Drawable {
    fun draw()
}

abstract class Shape(var color: String) : Drawable {
    abstract fun calcArea(): Double
    override fun draw() = println("Shape drawn")
}

class Circle(color: String, val radius: Double) : Shape(color) {
    override fun calcArea() = Math.PI * radius * radius
}

Wichtige Merkmale:

Schnittstellen erlauben mehrfache Implementierung, abstrakte Klassen nur eine
Schnittstellen können keinen Zustand speichern, abstrakte Klassen können
Eine abstrakte Klasse kann Teile von Schnittstellen implementieren und eigene gemeinsame Logik enthalten

Fragen mit Fallstricken.

Können Schnittstellen Eigenschaften mit backing field enthalten?

Nein, sie können nur die Signatur einer Eigenschaft definieren, aber keine Daten speichern – Eigenschaften ohne backing field.

Kann man von mehreren Klassen erben?

Nein, Kotlin unterstützt nur einfache Klassenvererbung, aber mehrfache Implementierung von Schnittstellen.

Kann man einen Konstruktor in einer Schnittstelle deklarieren?

Nein, Schnittstellen unterstützen keine Konstruktoren, da sie keinen Zustand speichern – nur Verträge für Verhalten.

Typische Fehler und Antipatterns

Verwendung von abstract class anstelle von interface ohne Notwendigkeit
Speicherung von Zustand in interface (unmöglich, aber beim Design falsch gedacht)
Gestaltung von Klassenhierarchien, die die Erweiterung erschweren

Beispiel aus dem Leben

Negativer Fall

In der Anwendung wurden alle gemeinsamen Funktionen in eine abstrakte Klasse ausgelagert, selbst wenn es keine interne Logik oder Status gab, sondern nur einen gemeinsamen Vertrag erforderlich war.

Vorteile:

Ein einziger Änderungsort für gemeinsame Logik

Nachteile:

Probleme mit mehrfacher Vererbung, schwierige Integration mit anderen Strukturen

Positiver Fall

Nur die erforderlichen Verträge wurden in Schnittstellen ausgelagert, abstrakte Klassen beschränkten sich auf gemeinsame Eigenschaften und Methoden, die eine Implementierung erforderten.