Dependency injection
Dependency injection bir cümlə ilə: obyekt öz asılılıqlarını özü yaratmır, kənardan alır.
``` // yox: sinif özünü şəbəkəyə bağlayır class OrderRepo { final api = ApiClient(); }
// bəli: asılılıq kənardan verilir class OrderRepo { OrderRepo(this.api); final ApiClient api; } ```
Fərq testdə görünür: birinci variantda OrderRepo-nu real şəbəkə olmadan test etmək mümkün deyil; ikincidə saxta ApiClient vermək kifayətdir.
Flutter-də üç yanaşma yayılıb: konstruktor (ən sadə), `InheritedWidget`/Provider (ağac vasitəsilə), service locator (get_it — qlobal reyestr).
| Yanaşma | Üstünlük | Zəiflik |
|---|---|---|
| Konstruktor | Aşkardır — asılılıqlar imzada görünür | Dərin ağacda ötürmək yorucudur |
| Provider / Riverpod | Ağac boyu çatır, ömür idarə olunur | `BuildContext` tələb edir |
| Service locator (`get_it`) | Context lazım deyil, hər yerdən çatır | Asılılıq gizlənir — imzaya baxıb bilmək olmur |
Interview ipucu. Service locator sualı tələ ola bilər: get_it rahatdır, amma asılılığı gizlədir — sinifin imzasına baxıb nədən asılı olduğunu görmək mümkün olmur və bu, testdə unudulmuş mock kimi özünü göstərir. Güclü cavab: biznes siniflərində konstruktor injection istifadə edirəm, get_it-i isə yalnız kompozisiya nöqtəsində (obyektləri bir-birinə bağlayan yerdə) və ya context-in olmadığı yerlərdə saxlayıram.
📚 Mənbələr və sənədlər
- get_it paketipub.dev
Registrasiya növləri (singleton, lazy, factory) və scope-lar README-də izah olunub.
- Arxitektura bələdçisirəsmidocs.flutter.dev
- provider paketirəsmipub.dev