Bölüm 8 — Konu 40: Sound Null Safety Derinlemesine — `late`, `required`, Non-Nullable Varsayılan Davranış

Bölüm 2'de null safety'nin temellerini (?, ?., ??, !, late) görmüştük. Şimdi bunun "sound" (sağlam/kanıtlanabilir) olmasının ne anlama geldiğini ve daha ileri detaylarını işleyeceğiz.

#"Sound" Null Safety Ne Demek?

Dart'ın null safety sistemi, sadece bir "öneri" veya "uyarı" sistemi değildir — matematiksel olarak kanıtlanabilir bir garanti sunar: eğer bir değişken non-nullable (String gibi, String? değil) olarak tanımlandıysa, Dart derleyicisi bunun hiçbir koşulda null olamayacağını %100 garanti eder.

void main() {
  String isim = "Ahmet";
  // Bu satırdan sonra, kod içinde HİÇBİR yol yok ki 'isim' null olsun.
  // Bu, "sound" (sağlam) olmanın anlamı — derleyici bunu matematiksel olarak kanıtlayabilir.
  print(isim.length); // asla null reference hatası veremez, GARANTİ
}

Bu, örneğin TypeScript gibi bazı dillerin "null safety" yaklaşımından daha güçlüdür — TypeScript'te bazı durumlarda (özellikle JavaScript kütüphaneleriyle etkileşimde) tip sistemi "yanılabilir", ama Dart'ın sound null safety'si, dilin temelinde yer aldığı için bu tür kaçaklara izin vermez.

#late — Derinlemesine Kullanım Senaryoları

Bölüm 2'de late'i tanımıştık. Şimdi gerçek kullanım senaryolarını görelim.

#Senaryo 1: Sınıf Alanının Constructor Dışında Atanması

class VeriYoneticisi {
  late String veri; // constructor'da atanmıyor ama non-nullable

  void veriYukle() {
    veri = "Sunucudan gelen veri"; // burada atanıyor
  }

  void veriGoster() {
    print(veri);
  }
}

void main() {
  VeriYoneticisi yonetici = VeriYoneticisi();
  yonetici.veriYukle();
  yonetici.veriGoster(); // Sunucudan gelen veri
}

Burada veri, constructor'da hemen atanmıyor (çünkü belki bir API çağrısından sonra dolacak) ama String? yapmak da istemiyoruz çünkü mantıksal olarak, veriYukle() çağrıldıktan sonra bu alan asla null olmamalı. late, bu ara durumu doğru şekilde modellememizi sağlıyor.

Eğer veriYukle() çağrılmadan veriGoster() çağrılırsa:

void main() {
  VeriYoneticisi yonetici = VeriYoneticisi();
  yonetici.veriGoster(); // ❌ RUNTIME HATASI! LateInitializationError
}

Bu bir runtime hatası — late kullanmak, "bu değişkenin bir gün atanacağına söz veriyorum" demektir, ama Dart bunu derleme zamanında doğrulayamaz (çünkü hangi sırayla metod çağıracağını bilemez). Bu, late kullanırken bilinçli olman gereken bir risktir — Bölüm 2'de "riskli" olarak nitelediğimiz ! operatörüne benzer bir güven ilişkisi kurar.

#Senaryo 2: Pahalı Hesaplamaları Geciktirme (Lazy Initialization)

class Rapor {
  late final List<int> buyukVeriListesi = _agirHesaplamaYap();

  List<int> _agirHesaplamaYap() {
    print("Ağır hesaplama çalışıyor...");
    return List.generate(1000000, (i) => i);
  }
}

void main() {
  print("Rapor nesnesi oluşturuluyor");
  Rapor rapor = Rapor(); // "Ağır hesaplama çalışıyor..." henüz YAZDIRILMAZ!

  print("Şimdi veriye erişiyoruz");
  print(rapor.buyukVeriListesi.length); // İLK erişimde hesaplama çalışır
}

Çıktı:

Rapor nesnesi oluşturuluyor
Şimdi veriye erişiyoruz
Ağır hesaplama çalışıyor...
1000000

Bu, lazy initialization (tembel başlatma) denen bir kalıptır: late final, alanın değerinin ilk erişildiği anda hesaplanmasını sağlar, nesne oluşturulduğu anda değil. Eğer bu alana hiç erişilmezse, pahalı hesaplama hiç çalışmaz — bu, performans açısından değerli bir optimizasyondur (gereksiz işlem yapılmaz).

late final — İkisi Birlikte: Dikkat et, late ile final birlikte kullanılabilir — "geç başlatılacak ama bir kere atandıktan sonra değişmeyecek" anlamına gelir. Bu, late'in en yaygın kullanım şekillerinden biridir.

#required — Derinlemesine

Bölüm 5'te fonksiyon parametrelerinde required'ı görmüştük. Bunun null safety ile ilişkisini netleştirelim:

void kayitOlustur({required String kullaniciAdi, String? bio}) {
  print("Kullanıcı: $kullaniciAdi");
}

required, aslında null safety'nin fonksiyon parametrelerine uygulanmış halidir. kullaniciAdi, non-nullable (String, String? değil) olduğu için, zaten "bu asla null olamaz" garantisi taşıyor — ama named parametreler varsayılan olarak optional olduğundan, Dart'ın "bu parametrenin verilmesi zorunlu" olduğunu ayrıca belirtmen gerekiyor. required, bu iki kuralı (non-nullable olmalı + verilmesi zorunlu) birleştiriyor.

required olmadan non-nullable named parametre mümkün mü?

void ornek({String kullaniciAdi = "Misafir"}) {
  // required olmadan da non-nullable olabilir, EĞER varsayılan değer varsa
  print(kullaniciAdi);
}

Evet — eğer bir varsayılan değer verirsen, required yazmana gerek kalmaz, çünkü parametre hiç verilmese bile asla null olmayacağı garanti altındadır (varsayılan değer devreye girer).

#Non-Nullable'ın Varsayılan Davranışı — Neden Bu Kadar Katı?

class Kullanici {
  String isim; // varsayılan olarak non-nullable
  int yas;     // varsayılan olarak non-nullable

  Kullanici(this.isim, this.yas);
}

Dart'ın tasarım felsefesi şu: "Nullable olmak istisna olmalı, non-nullable olmak kural olmalı." Bu, birçok eski dilin (Java, C# başlangıçta, JavaScript) tam tersi bir yaklaşımdır — onlarda her şey varsayılan olarak nullable'dı ve sen özellikle "bu null olamaz" demen gerekiyordu (ya da hiç böyle bir mekanizma yoktu). Dart, bu durumu tersine çevirerek, geliştiricinin bilinçli olarak "bu değer null olabilir" demesini zorunlu kılıyor — bu, null ile ilgili hataların çoğunu daha kod yazılırken önlüyor.

#Migration (Geçiş) Notu — Eski Kod ile Yeni Kod

Dart 2.12 öncesi yazılmış kodlar (null safety olmadan) hâlâ var olabilir. Eğer eski bir pakete bağımlıysan, Dart bunu "legacy" (miras) tip sistemiyle ele alır — bu, ileri bir konu ve muhtemelen Flutter'a geçtiğinde nadiren karşına çıkacak bir durum, ama var olduğunu bilmen faydalı: eski, null-safety'siz kodla yeni kod bir arada çalışabilir, Dart bu geçişi yönetir.

#Null Safety'nin Koleksiyonlarla İlişkisi — Kısa Bir Hatırlatma

Bölüm 4'te Map üzerinde [] erişiminin neden nullable döndürdüğünü görmüştük (yaslar["Olmayan"] → null). Bu, sound null safety'nin koleksiyonlara tutarlı şekilde uygulanmasının bir örneğiydi — Dart, "bu anahtar var mı yok mu, derleme zamanında bilemem" dediği için, sonucu dürüstçe nullable olarak işaretliyor.

#🎯 Bu Dersten Çıkarılması Gerekenler

• Sound null safety, "bir değişken non-nullable ise asla null olamaz" garantisini matematiksel olarak kanıtlanabilir şekilde sağlar.
• late, hem "constructor dışında atanacak ama non-nullable" hem de "lazy initialization" (ilk erişimde hesaplama) senaryolarında kullanılır.
• late final, geç başlatılan ama bir kere atandıktan sonra değişmeyen alanlar için yaygın bir kombinasyondur.
• required, non-nullable + "verilmesi zorunlu" garantisini named parametrelere uygular; varsayılan değer varsa required gerekmez.
• Dart'ın felsefesi: nullable olmak istisna, non-nullable olmak kuraldır — bu, null hatalarının çoğunu kod yazılırken önler.

#📝 Ödevler

• [ ] late bir alan tanımla, önce atamadan erişip LateInitializationError hatasını gözlemle, sonra doğru sırada atayıp düzelt.
• [ ] late final ile lazy initialization örneği yaz — bir "pahalı hesaplama" fonksiyonunun sadece ilk erişimde çalıştığını print ile kanıtla.
• [ ] Named bir parametreyi hem required ile hem varsayılan değerle (ikisi ayrı örnekte) non-nullable yap, farklarını yorumla.
• [ ] Bir sınıfta, constructor'da hemen atanamayan ama "sonradan kesinlikle atanacak" bir alanı late ile modelle (örn. bir "kullanıcı profili yüklendiğinde dolacak" alan).
• [ ] Kendi cümlelerinle, "neden Dart varsayılan olarak her şeyi non-nullable yapıyor" sorusunu, bu dersten öğrendiklerinle açıkla.

Sıradaki konu: Bölüm 8 — Konu 41: assert ile Geliştirme Zamanı Kontrolleri