Bölüm 6 — Konu 28: Karşılaştırma — Hangi Projede Hangisi?

Bölüm 6'nın son konusundayız. Bu ders, yeni bir kavram öğretmiyor — Konu 23-27'de öğrendiğin her şeyi birleştirip, gerçek bir karar verme çerçevesi sunuyor.

#Hepsinin Ortak Temeli — Kısa Bir Hatırlatma

Bölüm 6 Konu 23'te öğrendiğimiz gibi, hepsi aynı temel mekanizmaya dayanıyor: InheritedWidget. Fark, bu mekanizmanın **üzerine hangi "arayüzün" (API) inşa edildiğidir:

InheritedWidget (Flutter'ın çekirdek mekanizması)
     │
     ├── Provider (elle InheritedWidget yazmanın kolaylaştırılmış hali)
     │      │
     │      └── flutter_bloc (Provider'ı arka planda kullanır)
     │
     ├── Riverpod (context bağımsız, daha tip güvenli bir yeniden tasarım)
     │
     └── GetX (kendi global registry sistemi, context'i tamamen atlar)

#Karşılaştırma Tablosu — Tüm Kriterler Bir Arada

#Proje Büyüklüğüne Göre Karar Rehberi

#Küçük Proje / Öğrenme Amaçlı / Hızlı Prototip

Öneri: Provider veya GetX

Bölüm 6 Konu 24'te öğrendiğimiz Provider, az kavramla (watch/read/select) hızlı sonuç verir. GetX (Konu 27), daha da az kod ile benzer bir hız sunar. Bu aşamada, mimari kaygılardan çok, öğrenmeye ve hızlı iterasyona odaklanmak mantıklıdır.

#Orta Ölçekli Proje / Bireysel Geliştirici / Küçük Takım

Öneri: Riverpod

Bölüm 6 Konu 25'te öğrendiğimiz gibi, Riverpod'un context bağımsızlığı ve derleme zamanı güvenliği, projenin büyümesiyle birlikte daha az hata anlamına gelir. Provider'a çok benzer bir zihniyetle çalıştığı için, geçiş kolaydır.

#Büyük Ölçekli Proje / Çok Geliştiricili Takım / Kurumsal Uygulama

Öneri: Riverpod veya Tam BLoC

Bölüm 6 Konu 26'da öğrendiğimiz tam BLoC pattern'in event-driven yapısı, birden fazla geliştiricinin "bu state neden değişti" sorusunu, kod tabanının herhangi bir yerinden anlayabilmesini sağlar — bu, büyük takım koordinasyonu için değerlidir. Riverpod da, tip güvenliği ve test edilebilirliği sayesinde bu ölçekte gayet iyi çalışır.

#GetX Ne Zaman Mantıklı?

Bölüm 6 Konu 27'de dengeli bir şekilde işlediğimiz gibi, GetX'in hız avantajı, küçük-orta ölçekli, tek geliştiricili veya küçük takımlı projelerde değerlidir. Büyük, uzun soluklu projelerde, disiplinli kullanılmazsa (global state'in kontrolsüz büyümesi), bakım zorlaşabilir — bu yüzden büyük kurumsal projelerde daha az tercih edilir.

#Karar Verirken Sorman Gereken Sorular

1. Kaç kişi bu kod üzerinde çalışacak? Tek başınaysan, esneklik önceliklidir. Takım büyüdükçe, yapı ve öngörülebilirlik daha değerli hale gelir.
2. Proje ne kadar uzun soluklu? Kısa ömürlü bir MVP/prototip için, hız öncelikli. Yıllarca sürecek bir uygulama için, sürdürülebilirlik öncelikli.
3. Test yazmayı ne kadar önemsiyorsun? Dart Bölüm 12 Konu 55'te öğrendiğimiz unit test kültürü güçlüyse, Riverpod/BLoC'un test edilebilirlik avantajı öne çıkar.
4. Ekibin önceden bir deneyimi var mı? Zaten bir ekip Provider veya BLoC biliyorsa, tutarlılık için aynı aracı kullanmak genelde en mantıklısıdır — "en iyi" araç yerine "ekibin bildiği" araç, pratikte genelde kazanır.

#Bu Tutorial'da Bundan Sonra Ne Kullanacağız?

Flutter tutorial'ının ilerleyen bölümlerinde (özellikle Bölüm 7'de mimari konularında, ve daha ileri projelerde), genellikle Provider veya Riverpod örnekleri kullanacağız — çünkü bunlar, Flutter ekibinin resmi dokümantasyonunda en çok referans verilen, ve Bölüm 6 Konu 23'te öğrendiğimiz temel InheritedWidget mekanizmasına en yakın duran araçlardır. Ama artık hepsinin temel mantığını bildiğin için, hangi projede hangisiyle karşılaşırsan karşılaş, hızlıca adapte olabileceksin.

#Değişmeyen Gerçek — Hangisini Seçersen Seç

Bölüm 6'nın tamamında öğrendiğimiz en önemli ders, aslında araçların kendisinden bağımsız:

• Dart Bölüm 6'da öğrendiğimiz encapsulation (state'i private tutup, kontrollü metodlarla değiştirme) her zaman önemlidir — hangi aracı kullanırsan kullan.
• Dart Bölüm 4'te öğrendiğimiz immutable koleksiyonlar (List.unmodifiable gibi), state'in dışarıdan kontrolsüzce değiştirilmesini önlemede her zaman değerlidir.
• Bölüm 2 Konu 6'da öğrendiğimiz setState()'in temel rebuild mekanizması, hangi state management aracını kullanırsan kullan, arka planda hâlâ çalışıyor — bu araçlar, setState()'in yerini almaz, onu daha organize bir şekilde tetiklemenin yollarını sunar.

#🎯 Bu Dersten Çıkarılması Gerekenler

• Provider, Riverpod, BLoC ve GetX, hepsi temelde InheritedWidget'a dayanır, farklı "arayüzler" sunarlar.
• Küçük/prototip projeler için Provider veya GetX; orta ölçek için Riverpod; büyük, çok geliştiricili projeler için Riverpod veya tam BLoC genelde tercih edilir.
• Karar verirken: takım büyüklüğü, projenin ömrü, test kültürü ve ekibin önceki deneyimi göz önünde bulundurulmalıdır.
• Hangi aracı seçersen seç, temel prensipler (encapsulation, immutability, setState()'in arka planda çalışan rebuild mekanizması) değişmez.

#📝 Ödevler

• [ ] Kendi hayalindeki bir proje fikri düşün (örn. bir not alma uygulaması), yukarıdaki karar rehberine göre hangi state management aracını seçeceğine karar ver ve gerekçelendir.
• [ ] Aynı basit uygulamayı (örn. sayaç), Bölüm 6'da öğrendiğin 4 araçtan (Provider, Riverpod, Cubit, GetX) en az ikisiyle yazıp, kod miktarı ve okunabilirlik açısından karşılaştır.
• [ ] Kendi cümlelerinle, "state management aracı seçmek, setState()'in yerini almak değil, onu organize etmenin bir yoludur" cümlesini açıkla.
• [ ] Bir arkadaşına (ya da kendine), hangi durumda hangi aracı önereceğini anlatan kısa bir "karar ağacı" (flowchart tarzı, metin olarak da olabilir) yaz.

#🏁 Bölüm 6 Tamamlandı!

State management'ın temellerini (InheritedWidget) ve dört büyük çözümünü (Provider, Riverpod, BLoC/Cubit, GetX) öğrendin — artık hem neden bu araçlara ihtiyaç duyulduğunu hem de her birinin nasıl çalıştığını biliyorsun, ve projene göre bilinçli bir seçim yapabiliyorsun.

Sıradaki durak Bölüm 7 — İleri Navigasyon & Mimari: Navigator 2.0, go_router, deep linking, repository pattern, dependency injection ve Clean Architecture ile, büyük, sürdürülebilir uygulamalar kurmayı öğreneceğiz.