Cevap.

Konu geçmişi:

Kotlin, Java'nın en iyi yönlerini ve JVM'nin işlevsel mirasını birleştirmiştir. Normal sınıflar, standart yapılar olarak tanımlanır, soyut sınıflar, varsayılan bir uygulama ile eksik tanımlı şablonlar oluşturmayı sağlar ve arayüzler, durum olmadan davranışın çoklu kalıtımını destekler.

Sorun:

Sınıf, soyut sınıf ve arayüz arasında doğru seçim, uygulamanın mimarisini, kodun granülerliğini ve genişleyebilirliğini belirler. Yanlış kalıtım, test etme ve gelecekteki değişiklikler açısından zorluklara yol açar.

Çözüm:

Kotlin'de:

Normal sınıf: yapıyı ve davranışı tanımlar. open olarak ilan edilirse kalıtım alınabilir.
Soyut sınıf: doğrudan oluşturulamaz. Uygulama ve/veya soyut (gövdesiz) yöntemler içerebilir.
Arayüz: dolaylı olarak açıktır, sözleşmeleri uygular, yöntemlerin uygulanmasına izin verir, ancak durum tutamaz (yalnızca backing field olmayan özellikler).

Kod örneği:

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
}

Ana özellikler:

Arayüzler çoklu uygulamayı sağlar, soyut sınıflar yalnızca birini
Arayüzler durum tutamaz, soyut sınıflar tutabilir
Soyut sınıf, arayüzlerin bir kısmını uygulayabilir ve kendi genel mantığını içerebilir

Kandırmaca Sorular.

Arayüzler, backing field ile özellikler içerebilir mi?

Hayır, yalnızca özelliğin imzasını tanımlayabilirler, ancak verileri depolayamazlar - yalnızca backing field olmayan özellikler.

Birden fazla sınıftan miras alabilir miyim?

Hayır, Kotlin yalnızca tekil sınıf kalıtımını destekler, ancak arayüzlerin çoklu uygulamasını destekler.

Arayüzde yapıcı ilan edilebilir mi?

Hayır, arayüzler yapıcıları desteklemez, çünkü durum tutmazlar - yalnızca davranış sözleşmesini.

Yaygın hatalar ve anti-paterner

Gereksiz yere arayüz yerine soyut sınıf kullanmak
Arayüzde durum tutmak (mümkün değil, ancak tasarım sırasında hata yapılabilir)
Genişlemeyi zorlaştıran sınıf hiyerarşileri tasarlamak

Gerçek hayattan bir örnek

Olumsuz durum

Uygulamaya tüm ortak fonksiyonlar, içinde herhangi bir mantık veya durum olmasa bile, soyut bir sınıfa taşındı, sadece genel bir sözleşmeye ihtiyaç varken.

Artılar:

Ortak mantığın tek bir değişim noktası

Eksiler:

Çoklu kalıtım sorunları, diğer yapılarla zor entegrasyon

Olumlu durum

Sadece gerekli sözleşmeleri arayüzlere taşıdılar, soyut sınıfları genel özellikler ve uygulama gerektiren yöntemlerle sınırladılar.