Question 1

extends, implements və with arasındakı fərqi izah et.

Accepted Answer

Üçünü bir cümlə ilə ayır, sonra detallandır: extends implementasiyanı miras alır, implements yalnız müqaviləni götürür, with isə implementasiyanı iyerarxiya qurmadan qoşur. Detallar: extends — bir dənə olur, super.method() işləyir, konstruktorlar zəncirlənir. "X bir növ Y-dir" münasibətini bildirir. implements — neçə dənə olsa olar; heç nə miras qalmır, bütün üzvləri yazmalısan. Ən vacib Dart nüansı: hər class implicit interfeys yaradır, ona görə implements PaymentGateway konkret class üzərində də mümkündür — testdə fake qurmağın ən ucuz yolu budur. with — neçə dənə olsa olar, implementasiya gəlir; mixin-lər linearizasiya olunur, super zənciri yaranır. Sonda praktik seçim qaydası ver: davranışı paylaşmaq lazımdırsa mixin və ya kompozisiya, sadəcə tip müqaviləsi lazımdırsa implements, real "is-a" münasibəti varsa extends.

Question 2

Dart 3-də class modifiers niyə əlavə olundu və hansını nə vaxt seçirsən?

Accepted Answer

Səbəbdən başla: Dart 2-də hər class həm extend, həm implement oluna bilirdi. Paket müəllifi üçün bu o demək idi ki, class-a yeni metod əlavə etmək breaking change-dir — kimsə onu implement edibsə, kodu sınır. Modifiers bu qərarı müəllifin öz əlinə verdi. Sonra seçim cədvəlini danış: final — heç kim extend/implement edə bilməz. Paketdə default seçimim budur, çünki sonradan yumşaltmaq asan, sərtləşdirmək isə breaking-dir. interface — yalnız implement; müqavilə verirəm, implementasiyamı yox. base — yalnız extend; hər instansiyanın mənim state və invariant-larımı daşımasına zəmanət verir. Yoluxucudur: alt tiplər də base/final/sealed olmalıdır. sealed — bağlı variant çoxluğu, exhaustive switch. mixin class — həm with, həm extends ilə işlədilə bilən tip. Yekun: application kodunda çox vaxt heç bir modifier lazım deyil; modifiers ilk növbədə kitabxana sərhədi üçün alətdir. Bu son cümlə cavabı balanslı göstərir.

Question 3

Sealed class ilə exhaustive switch-i real bir ssenaridə necə istifadə edərdin?

Accepted Answer

Konkret ssenari seç — ən yaxşısı ekran state-i və ya şəbəkə nəticəsi. sealed class LoadState<T> və üç alt tip: Loading, Success(data), Failure(error). Sonra switch ifadəsi (statement yox) ilə hər variantı emal edirəm: switch (state) { Loading() => ..., Success(:final data) => ..., Failure(:final error) => ... }. default yazmıram — bu, qəsdəndir. Faydanı iki bənddə izah et: 1. Yeni variant (Empty) əlavə edən kimi bütün switch-lər kompilyasiya olunmur və kompilyator düzəldiləsi yerlərin siyahısını verir. Yəni "bu state-i emal etməyi unutduq" tipli bug artıq runtime-a çıxmır. 2. Pattern matching ilə destructuring pulsuz gəlir: Success(:final data) dərhal dataya çıxış verir, as cast və is yoxlaması lazım gəlmir. when şərti ilə əlavə şaxə də yazmaq olur. Əgər Flutter-dən soruşsalar, bir cümlə kifayətdir: bu pattern UI-nin bütün mümkün state-lərini tip sistemində qeyd etməyə imkan verir. Ehtiyat: variant sayı çox böyüyürsə (10+), sealed hierarchy ağırlaşır — o zaman ayrı-ayrı kiçik state-lərə bölmək daha yaxşıdır.

Question 4

sealed və final class arasındakı fərq nədir?

Accepted Answer

Səthi cavab "ikisi də alt tipləri məhdudlaşdırır" olar — bu, ən çox edilən səhvdir. Fərqi dəqiq göstər: final class — kənardan extend/implement qadağandır, amma eyni kitabxanada istənilən qədər alt tip ola bilər və kompilyator onların tam siyahısını nəzərə almır. Class özü instansiya edilə bilər. sealed class — implicitly abstract (instansiya edilmir) və implicitly final. Əlavə olaraq kompilyatora deyir ki, bütün birbaşa alt tiplər bu kitabxanadadır və o siyahını exhaustiveness yoxlamasında istifadə edir. Yəni əsas fərq: final sadəcə qapayır, sealed isə qapayır və kompilyatora tam variant çoxluğunu bildirir. Praktik nəticə: sealed tipi üzərində default-suz switch yazmaq olur, final üzərində yox. Bir nüans da əlavə et: sealed başqa modifierlə birləşmir (sealed final yoxdur), çünki onların ikisini də özündə daşıyır. Alt tipləri isə adətən final elan edirlər — beləliklə həm variant çoxluğu bağlı olur, həm də hər variant kənardan genişləndirilə bilmir.

Question 5

Layihəndə base modifier-dən istifadə etmisən? Onu nə vaxt seçmək düzgündür?

Accepted Answer

Dürüst cavab formatı: əvvəlcə nə problemi həll etdiyini izah et, sonra öz təcrübəndən nümunə ver (yoxdursa, açıq de ki, application kodunda ehtiyac olmayıb — bu, zəiflik deyil). base bir şeyə zəmanət verir: bu tipin hər instansiyası mənim real implementasiyamı daşıyır. Çünki kənardan yalnız extends mümkündür, implements yox. Bu, o hallarda vacibdir ki, class-ın metodları bir-birindən asılıdır və ya daxili state invariant saxlayır — məsələn, bir metod _cache-i doldurur, o biri onu oxuyur. Kimsə implements etsə, o daxili əlaqə tamamilə itir və sənin close() metodunun çağırılacağına heç bir zəmanət qalmır. Mütləq "yoluxuculuq" xüsusiyyətini də de: base class-ın hər alt tipi də base, final və ya sealed olmalıdır. Bu, qəsdəndir — zəncirin heç bir yerində implements ilə boşluq açıla bilməsin. Praktik nəticə: base istifadəçiyə xərc yükləyir (test-də fake qurmaq çətinləşir, mocktail kimi paketlər implements-ə söykənir), ona görə onu yalnız real invariant qorumaq lazım olanda seçirəm — yoxsa final və ya modifiersiz class daha sərfəlidir.

Modifier	Kitabxanadan KƏNARDA icazə verir	Nə üçündür
(modifiersiz) `class`	new, extends, implements	Dart 2 davranışı — ən sərbəst, ən qorumasız
`abstract class`	extends, implements (new yox)	Tam olmayan tip — birbaşa instansiya edilə bilməz
`base class`	yalnız extends; alt tiplər də base/final/sealed olmalıdır	Hər instansiyanın sənin implementasiyanı daşımasına zəmanət
`interface class`	yalnız implements	Müqavilə vermək, amma implementasiyanı miras verməmək
`final class`	nə extends, nə implements — yalnız istifadə	Gələcəkdə breaking change olmadan üzv əlavə etmək azadlığı
`sealed class`	heç nə (implicitly abstract + final)	Alt tiplərin tam siyahısı məlum — exhaustive switch
`mixin class`	extends, implements və `with`	Həm class, həm mixin kimi işlədilə bilən tip

Class modifiers: sealed, final, base, interface

📚 Mənbələr və sənədlər