Cevap

Kotlin, kalıtım parametrelerini open anahtar kelimesi ile destekler, ancak dilin ana önerisi — kalıtım yerine kompozisyona razı olmaktır. Bu, daha esnek ve genişletilebilir sistemler oluşturmanıza olanak tanır, hiyerarşilerin kırılganlığını ve derin kalıtım ile ilgili sorunları önler.

Kompozisyon , sınıfın bir alanı olarak gereken türden bir nesneyi dahil edip, onun uygulamasını kalıtım yoluyla almak yerine ona iş yükü devretmektir. Kotlin, by anahtar kelimesi ile delegasyon desenini kolaylaştırır ve arayüz uygulamalarını nesnelere otomatik olarak devretmenizi sağlar.

Delegasyon deseni örneği:

interface Logger {
    fun log(message: String)
}

class ConsoleLogger : Logger {
    override fun log(message: String) = println(message)
}

class Service(private val logger: Logger) : Logger by logger {
    fun doAction() {
        log("Eylem yapıldı")
    }
}

fun main() {
    val service = Service(ConsoleLogger())
    service.doAction() // Çıktı: Eylem yapıldı
}

Bu yaklaşım, kodun yeniden kullanımını kolaylaştırır ve mantığı daha modüler hale getirir.

Kandırmacalı Soru

"Data sınıfı başka bir sınıftan, örneğin soyut bir sınıftan kalıtım alabilir mi?"

• Cevap: Kotlin'deki data class, başka bir sınıftan (arayüzler dışında) kalıtım alamaz, çünkü data class her zaman finaldir. Tek istisna, arayüzlerdir, bunları uygulamak mümkündür.

Örnek:

abstract class Base(val name: String)
data class Derived(val age: Int, val name: String) : Base(name) // Derleme hatası: data class Base sınıfını süremez

Ama şu mümkündür:

interface User

data class Admin(val name: String, val rights: List<String>) : User

Konuyla ilgili ince ayrıntıları bilmemekten kaynaklanan gerçek hataların örnekleri

---

Hikaye

Projede birkaç hizmetin ortak bir soyut sınıftan kalıtım almasına karar verildi, böylece tekrarlayan mantığı uygulayabilirsiniz. Sonuçta, birçok kalıtım seviyesi oluştu, hata ayıklama zorlaştı, test sorunları ortaya çıktı. Kompozisyona ve delegasyona (arayüzler ve bağımlılık enjeksiyonu yoluyla) geçtikten sonra kodu basitleştirmek, daha modüler hale getirmek ve test kapsamını artırmak mümkün oldu.

---

Hikaye

Acemi bir geliştirici, ortak işlevsellik eklemek için bir data class'ı başka bir sınıfla genişletmeye çalışıyordu. Kod derlenmedi, ancak programcı sebebini uzunca anlayamadı (Kotlin'deki data class sınırları).

---

Hikaye

Geniş bir kayıt mantığına sahip bir projede, kayıt işlevselliğini temel sınıfa aktarmaya karar verdik. Ancak sistemin büyümesiyle birlikte bazı hizmetler farklı kayıt uygulamaları gerektiriyordu. Logger arayüzü ve delegasyon yoluyla kompozisyon kullanarak yeniden yapılandırmak zorunda kaldık, bu da mimariyi önemli ölçüde basitleştirdi.