Cevap

Sorunun Tarihçesi

Kotlin'in erken sürümlerinde, tür hiyerarşisini sınırlamak için sealed sınıflar kullanıldı; bu, geliştiricilerin alt türleri açıkça kontrol etmesine olanak tanıdı ve yalnızca tek bir dosya içinde varislerin tanımını sınırladı. Bazı durumlar için bu yeterli değildi, özellikle de arayüzlerle benzer hiyerarşileri tanımlamak gerektiğinde. Bu sorunu çözmek için Kotlin 1.5 ile birlikte arayüzler için sealed modikatörü tanıtıldı.

Problem

Normal arayüzler, projede herhangi bir yerde uygulanabilir, bu da çoğu zaman tür hiyerarşisinin mutlak kapalı olmasını sağlamaya engel olur ve eksiksiz tür kontrolü (exhaustive checks) kullanmayı zorlaştırır. Bu, çalışma zamanında hatalara, tüm durumları statik olarak kontrol edememeye yol açabilir.

Çözüm

Sealed arayüzler, bir dosya içinde uygulama sınıflarının listesini sınırlamaya olanak tanır, bu da tür sisteminin öngörülebilirliğini artırır ve örüntü eşleştirme (pattern matching) güvenliğini sağlar.

sealed interface NetworkResult
class Success(val data: String): NetworkResult
class Failure(val error: Throwable): NetworkResult

fun handle(result: NetworkResult) = when(result) {
    is Success -> println("Data: ${result.data}")
    is Failure -> println("Error: ${result.error}")
    // Tüm durumlar göz önünde bulundurulmuş, 'else' gerekmez
}

Anahtar özellikler:

Sealed arayüzler tekil bir hiyerarşi kabul eder: yalnızca aynı dosyadan sınıflar/nesneler miras alabilir
Sealed arayüzler hem sınıflar hem de nesneler tarafından uygulanabilir
When ifadesinin tür güvenliğini artırır, 'else' ifadesini barındırma zorunluluğunu ortadan kaldırır

Yanıltıcı Sorular

Sealed arayüzü ayrı bir dosyaya eklemek ya da başlangıç dosyasının dışındaki bir yerde uygulamak mümkün mü?

Hayır. Sealed arayüzü doğrudan uygulayan tüm türler, aynı dosyada tanımlanmalıdır; aksi takdirde derleyici hata verir.

Sealed arayüzün, tanım dosyasının dışında alt arayüzlere sahip olması izin veriliyor mu?

Hayır. Alt arayüzler de aynı dosyada olmalıdır. Tüm hiyerarşi dosya içinde kapalıdır.

Sealed arayüzler, çalışma zamanı performansını etkiler mi?

Doğrudan etkileyemez, fakat zaman tasarrufu sağlamak için güvenli tür kontrollerinin derleme aşamasında kullanılmasına olanak tanır; bu da çalışma zamanı hatası olasılığını azaltır, kodu basitleştirir ve dolaylı olarak test süresini hızlandırabilir.

Tipik Hatalar ve Antipattern'ler

Sealed arayüzü uygulayan sınıfların, arayüzün tanımlandığı dosyanın dışında ilan edilmesi
Çok fazla durum eklenmesi, bu da bakım sürecini zorlaştırır
Sealed arayüz kullanımında, eğer durum hiyerarşisi değişebilir ise (kapalı bir durum listesi gerekmiyor) kullanılması

Gerçek Hayattan Bir Örnek

Negatif Durum

Bir geliştirici, sealed arayüz NetworkAction'ı bir dosyada tanımlar, ancak uygulamalar farklı sınıflar ve dosyalar arasında dağınık olarak yer alır. Sorun geç bir zamanda ortaya çıkar: derleyici kuralın ihlal edildiğini bildirir, yapıyı düzeltmek zordur, özellikle büyük bir projede.

Artıları:

Yeni uygulamaların eklenmesine izin verir, tek bir dosyayı düzenlemeden

Eksileri:

Tür güvenliği garantilerini ihlal eder
Kodun yeniden yapılandırılmasını gerektirir, bu da zaman açısından pahalıdır

Pozitif Durum

Sealed arayüz OrderResult ve Success/Failure sınıfları tek bir dosya içinde tanımlanır. When kontrolü her zaman eksiksizdir, hiçbir dal atlanmaz.