Kotlin'de "sealed class" nedir ve durumların işlenmesini nasıl basitleştirir? Sealed class'lar when ifadesiyle nasıl ilişkilidir ve bu neden type-safety için önemlidir? Bir kullanım örneği verin.

Cevap

Kotlin'de sealed class, alt sınıf hiyerarşisini kısıtlayan bir soyut sınıftır: tüm alt türler bir dosyada tanımlanmalıdır. Bu, alternatiflerin setinin sabit olduğu hiyerarşiler için kullanışlıdır (örneğin, durumlar, olaylar veya hataları tanımlamak için):

sealed class Result {
    object Success : Result()
    data class Error(val message: String) : Result()
    object Loading : Result()
}

fun handle(result: Result) = when (result) {
    is Result.Success -> print("Başarı!")
    is Result.Error -> println("Hata: ${result.message}")
    is Result.Loading -> println("Yükleniyor...")
}

When ile İlişki: Tüm sealed class alt türlerini when ifadesinde kullanıyorsak, derleyici kapsamlılık (exhaustiveness) kontrolü yapar. Bu, yeni bir durum eklenirse, geliştiricinin yeni alternatifin işlenmediği durumlarda bir derleme hatası almasını garanti eder.

Bunun Önemi:

• Type-safety'nin korunmasını kolaylaştırır.
• Runtime kontrollerinden bağımsızlık, işleme derleme aşamasında yapılır.
• Hiyerarşinin tüm alternatiflerini açıkça göz önünde bulundurulmaya zorlar.

---

Kandırmaca Soru

"Sealed class alt türlerini farklı dosya veya paketlerde tanımlamak mümkün mü? Bu type-safety'yi nasıl etkiler?"

Cevap: Hayır, sealed class'ın tüm doğrudan alt türleri tek bir dosyada tanımlanmalıdır. Bu, type-safety'nin garantileri için derleyici kontrolüdür. Alt türler diğer dosyalar içinde yer alırsa, derleyici hata verir.

---

Konunun inceliklerini bilmemek nedeniyle yaşamış gerçek hata örnekleri

---

Hikaye

Ödeme iş mantığı tasarlanırken, işlem sonuçları için alternatifler eklenip, when ifadesinin güncellenmesi unutuldu. Ancak sealed class sayesinde, derleyici dikkate alınmayan durumları belirtti. Başka bir Java projesinde bu senaryo, başlatılmamış bir durumu ürüne götürebilirdi.

---

Hikaye

Projede sealed class'ın bazı verileri, normal open class'lara geçiş yaptıktan sonra, kapsamlı when kontrolleri çalışmamaya başladı — yeni durumlar işleme mantığında "kaybolmaya" başladı, bu da kullanıcı arayüzünün hatalı davranışına yol açtı.

---

Hikaye

E-ticaret sisteminde, sealed class alt türlerinin ayrı dosyalara çıkarılması (her biri, tekrar kullanım için farklı bir modülde) üzerinden mimarinin optimize edilmesi denendi. Bu, derlemeyi bozdu ve yayım öncesinde acil bir yeniden yapılandırmayı gerektirdi.