Antwoord.

Achtergrond:

Kotlin heeft de beste aspecten van Java en de functionele erfelijkheid van de JVM samengevoegd. Normale klassen worden gedeclareerd als standaardstructuren, abstracte klassen stellen je in staat om ondergedefinieerde sjablonen met standaardimplementatie te creëren, en interfaces ondersteunen meervoudige overdracht van gedrag zonder status.

Probleem:

De juiste keuze tussen een klasse, abstracte klasse en interface bepaalt de architectuur van de applicatie, de granulariteit van de code en de uitbreidbaarheid. Onjuiste overerving leidt tot testcomplexiteit en toekomstige wijzigingen.

Oplossing:

In Kotlin:

Gewone klasse: definieert structuur en gedrag. Kan worden overgeërfd door open te verklaren.
Abstracte klasse: kan niet rechtstreeks worden gemaakt. Kan implementatie en/of abstracte (zonder lichaam) methoden bevatten.
Interface: impliciet open, implementeert contracten, staat implementatie van methoden toe, maar slaat geen status op (alleen eigenschappen zonder backing field).

Voorbeeldcode:

interface Drawable {
    fun draw()
}

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

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

Belangrijke kenmerken:

Interfaces staan meervoudige implementatie toe, abstracte klassen slechts één.
Interfaces kunnen geen status opslaan, abstracte klassen kunnen dat wel.
Een abstracte klasse kan een deel van de interfaces implementeren en eigen gemeenschappelijke logica bevatten.

Misleidende vragen.

Kunnen interfaces eigenschappen met een backing field bevatten?

Nee, ze kunnen alleen de handtekening van de eigenschap definiëren, maar geen gegevens opslaan — eigenschappen zonder backing field.

Kan je van meerdere klassen erven?

Nee, Kotlin ondersteunt alleen enkelvoudige overerving van klassen, maar meervoudige implementatie van interfaces.

Kan je een constructor in een interface declareren?

Nee, een interface ondersteunt geen constructors, omdat hij geen status opslaat — alleen een gedragcontract.

Typefouten en antipatterns

Gebruik van abstracte klassen in plaats van interfaces zonder noodzaak.
Status opslaan in een interface (niet mogelijk, maar wordt foutief ontworpen).
Ontwerpen van klassehiërarchieën die uitbreiding bemoeilijken.

Voorbeeld uit het leven

Negatief geval

In de applicatie werden alle gemeenschappelijke functies in een abstracte klasse geplaatst, zelfs als er geen interne logica of status was, terwijl de behoefte gewoon een algemeen contract was.

Voordelen:

Één wijzigingspunt voor de gemeenschappelijke logica.

Nadelen:

Problemen met meervoudige overerving, moeizame integratie met andere structuren.

Positief geval

Alleen de nodige contracten zijn in interfaces geplaatst, abstracte klassen zijn beperkt tot gemeenschappelijke eigenschappen en methoden die implementatie vereisen.