Antwoord

Standaard zijn alle klassen, methoden en eigenschappen in Kotlin final. Dit betekent dat ze niet geërfd of overschreven kunnen worden, tenzij expliciet de modifier open is opgegeven.

Het sleutelwoord open staat overerving van een klasse of het overschrijven van een methode toe. Dit is fundamenteel anders dan in Java, waar klassen standaard open zijn voor overerving.

Voorbeeld:

open class Animal {
    open fun sayHello() {
        println("Hallo van Animal!")
    }
}

class Dog : Animal() {
    override fun sayHello() {
        println("Woef!")
    }
}

• Als je open uit de klasse Animal verwijdert, zal een poging tot overerving leiden tot een compileerfout.
• override is verplicht voor methoden/ eigenschappen die je wilt overschrijven.
• Interfaces worden geïmplementeerd via het sleutelwoord interface en vereisen niet open.

Valkuilvraag

In Kotlin kun je elke klasse overerven zoals in Java?

Antwoord: Nee, alleen klassen gemarkeerd met open (of abstract). Gewone klassen zijn final en kunnen niet geërfd worden. Dit is gedaan voor meer veiligheid en voorspelbaarheid van de code.

Voorbeeld van foute code:

class Animal
class Dog : Animal() // Compileerfout: "Animal" is final

Voorbeelden van echte fouten door onbekendheid met de nuances van het onderwerp

---

Verhaal

In een project voor het Android-platform probeerde een jonge ontwikkelaar een gebruikerscomponent te erven van een aangepast View-klasse, en vergat open toe te voegen. De build viel uit elkaar, de oorzaak was niet duidelijk, en de deadlines werden verschoven. Het probleem werd pas ontdekt na zorgvuldige bestudering van het compilerbericht.

---

Verhaal

Bij de ontwikkeling van een SDK vereiste de specificatie een uitbreidbare basis klasse, maar deze was zonder open gedeclareerd. Na levering aan klanten bleek dat de bibliotheek niet kon worden uitgebreid zonder wijzigingen aan de broncode. Er moest een update worden uitgebracht.

---

Verhaal

In een van de projecten migreerden ze oude Java-code naar Kotlin, zonder rekening te houden met de geslotenheid van klassen standaard. Het merendeel van de unit-tests die mocks gebruikten, stopte met compileren, wat het releaseproces vertraagde. Pas na massale toevoegingen van open werd het probleem opgelost.