Mobil İnkişafda Memarlıq və Nümunələr: Bunlar Nədir, Hansı Növləri Var və Necə Tətbiq Edilir

Əsas Memarlıq Nümunələri

Memarlıq nümunəsi məsuliyyətlərin tətbiq sinifləri arasında necə paylanacağını müəyyən edir. Nümunənin seçimi yeni ekranlar əlavə etmək və kodu sınamaq asanlığına təsir edir.

MVC (Model-View-Controller)

MVC klassik nümunədir, burada Model məlumatları, View göstərilməni, Controller isə məntiqi idarə edir. iOS-da MVC standartdır (UIViewController); Android-də Activity. Dezavantaj odur ki, Controller tez-tez "böyük" (Massive View Controller) olur. iOS tərtibatçı sorğusuna (Reddit, 2025) görə, 62% köhnə layihələrdə oxunmayan kodun əsas səbəbi kimi MVC-ni göstərir.

MVP (Model-View-Presenter)

MVP onunla fərqlənir ki, Presenter View-i interfeys vasitəsilə idarə edir, sınaq qabiliyyətini yaxşılaşdırır. MVP Jetpack-dən əvvəl Android-də məşhur idi, lakin rahatlıq baxımından MVVM-dən geri qalır.

MVVM (Model-View-ViewModel)

MVVM Google tərəfindən Android və Apple tərəfindən iOS üçün tövsiyə olunan nümunədir. ViewModel vəziyyəti saxlayır və View Data Binding və ya @Published vasitəsilə dəyişikliklərə abunə olur. ViewModel View-dən asılı deyil və sınamaq asandır. IT Sectr-də bütün layihələrdə əsas nümunə kimi MVVM-dən istifadə edirik.

MVI və VIPER

MVI reaktiv nümunədir, burada hər bir hərəkət Intent → Model → View dövrünü izləyir. MVI proqnozlaşdırıla bilən vəziyyəti təmin edir. VIPER beş qatlı (View, Interactor, Presenter, Entity, Router) iOS nümunəsidir, maksimum izolyasiya təmin edir, lakin çox sayda şablon kodu tələb edir.

Clean Architecture

Clean Architecture Robert Martin-in konsepsiyasıdır, tətbiqi qatlara bölür: xarici qatlar (UI, DB, şəbəkə) daxili qatlardan (biznes məntiqi, varlıqlar) asılıdır. Mobil inkişafda Clean Architecture üç qatı əhatə edir: data (depolar), domain (Use Cases) və presentation (ViewModels, UI).

Repository Pattern Clean Architecture-ın əsas komponentidir, məlumat mənbəyini abstraksiya edir. Depo məlumatı şəbəkədən və ya yerli yaddaşdan (Room, Core Data) gətirib-gətirməyəcəyinə qərar verir və vahid format qaytarır. Google-a (Architecture Guide, 2025) görə, Repository Pattern şəbəkə sorğuları olan istənilən tətbiq üçün tövsiyə olunur. Clean Architecture 3–5 ekran və ya daha çox olan layihələrdə əsaslandırılır — sadə tətbiqlər üçün MVVM ilə başlayın.

Yaradıcı Nümunələr

Singleton

Singleton sinfin tək nüsxəsini təmin edən və ona qlobal giriş nöqtəsi təmin edən memarlıq nümunəsidir. Verilənlər bazası, tənzimləmə meneceri və keş üçün istifadə olunur. Kotlin-də object vasitəsilə yaradılır. Dezavantaj qlobal vəziyyət səbəbindən sınağı çətinləşdirməsidir.

Factory və Builder

Factory obyekt yaradılmasını fabrik metoduna həvalə edir — new əvəzinə fabriki çağırırsınız. Builder çoxsaylı parametrləri olan mürəkkəb obyektlər (AlertDialog.Builder, NotificationCompat.Builder) üçün addım-addım qurma nümunəsidir. Builder oxunaqlılığı yaxşılaşdırır və obyektlərin yığıldıqdan sonra dəyişməz qalmasına imkan verir.

Struktur və Davranış Nümunələri

Adapter, Facade, Delegate, Protocol

Adapter bir sinfin interfeysini müştərinin gözlədiyi interfeysə çevirən memarlıq nümunəsidir. Android-də bu RecyclerView.Adapter-dır. Facade mürəkkəb sistemə sadələşdirilmiş interfeys təmin edir — məsələn, autentifikasiya detallarını gizlədən API üçün fasad. Delegate obyektin tapşırığı həvalə etdiyi iOS nümunəsidir (UITableViewDelegate). Protocol Swift-də interfeysin ekvivalentidir.

Observer və Strategy

Observer dəyişikliklər üçün abunə nümunəsidir: subyekt abunəçilərə yeniləmələr barədə məlumat verir. Mobil inkişafda Observer LiveData, StateFlow, RxJava və Combine-ın əsasıdır. Strategy dəyişdirilə bilən alqoritmlər nümunəsidir: çoxsaylı if-else ifadələri olmadan fərqli strategiya (çeşidləmə, doğrulama) bağlayırsınız.

Asılılıq Enjeksiyonu və Vəziyyət İdarəetməsi

Dependency Injection obyektin asılılıqlarını özü yaratmaq əvəzinə xaricdən aldığı memarlıq nümunəsidir. new Database() əvəzinə, verilənlər bazasını konstruktor vasitəsilə ötürürsünüz. DI sınağı sadələşdirir — real verilənlər bazası əvəzinə Mock istifadə edə bilərsiniz — və tətbiqlərin dəyişdirilməsini asanlaşdırır. Məşhur DI çərçivələri: Dagger və Hilt (Android), Swinject (iOS), Koin (Kotlin). Google tərəfindən tövsiyə olunan Dagger üzərində sarğı olan Hilt, DI quraşdırmasını 3 dəfə azaldır.

Service Locator mərkəzi asılılıq reyestri olan DI alternatividir. Tətbiqi daha sadədir, lakin sinif asılılıqlarını gizlədərək sınağı çətinləşdirir. Müasir layihələr Hilt və ya Koin vasitəsilə DI-ya üstünlük verir.

Flutter-da Vəziyyət İdarəetməsi

Flutter-da vəziyyət idarəetməsi öz ekosistemidir. Redux — Actions → Reducer → State vasitəsilə dəyişiklikləri olan tək Store. Google-ın BLoC-u Stream vasitəsilə hadisələri və vəziyyətləri ayırır. Provider — 2023-cü ilə qədər Google tərəfindən Flutter üçün tövsiyə olunan sadə DI konteyneri. Riverpod — tərtib və sınaq problemlərini həll edən təkmilləşdirilmiş Provider. GetX — marşrutlaşdırma, DI və vəziyyət idarəetməsi olan mikro çərçivə. Başlanğıc Flutter tərtibatçıları üçün ən yaxşı sənədləşdirilmiş həllər kimi Provider və ya Riverpod-u tövsiyə edirik.

SOLID və DRY Prinsipləri

Xüsusi nümunələrlə yanaşı, hər hansı bir dil və çərçivədə tətbiq olunan ümumi memarlıq dizayn prinsipləri mövcuddur.

SOLID — obyekt yönümlü dizaynın beş prinsipi: Single Responsibility (bir sinif — bir tapşırıq), Open-Closed (genişlənməyə açıq, dəyişikliyə qapalı), Liskov Substitution (alt siniflər üst sinfi əvəz edə bilər), Interface Segregation (kiçik interfeyslər), Dependency Inversion (abstraksiyalardan asılılıq). Mobil inkişafda SRP ən faydalı prinsipdir: hər sinif yalnız bir şey edir. IT Sectr təcrübəsinə görə, SRP-nin pozulması kommersiya layihələrində sınaq problemlərinin 70%-nin səbəbidir.

// Пример: нарушение SRP
class UserManager {
    fun saveUser(user: User) { /* сохранение */ }
    fun validateEmail(email: String): Boolean { /* валидация */ }
    fun sendEmail(user: User) { /* отправка */ }
    fun formatUser(user: User): String { /* форматирование */ }
}

// Исправление: разделяем на отдельные классы
class UserRepository { fun save(user: User) {} }
class EmailValidator { fun isValid(email: String): Boolean {} }
class EmailService { fun send(user: User) {} }
class UserFormatter { fun format(user: User): String {} }

Kotlin nümunəsi dörd məsuliyyəti olan bir UserManager sinfini hər biri bir məsuliyyətə malik dörd sinfə necə çevirdiyimizi göstərir. Belə kodu sınamaq, dəyişdirmək və yenidən istifadə etmək daha asandır.

DRY (Don't Repeat Yourself) — kod təkrarlanmasından qaçın. Təkrarlanan məntiqi ümumi metodlara və ya siniflərə çıxarın. KISS (Keep It Simple, Stupid) — sadəlik zəriflikdən daha vacibdir. YAGNI (You Aren't Gonna Need It) — ehtiyac olmaya biləcək bir şey üçün kod yazmayın. Bu prinsiplər artıqlıq olmadan təmiz, saxlanıla bilən kod yazmağa kömək edir.

Android Platform Nümunələri

ViewModel (Android) UI vəziyyətini saxlamaq üçün Jetpack memarlıq komponentidir, ekran döndürməyə davamlıdır. ViewModel Activity-yə istinad saxlamır və avtomatik təmizlənir. LiveData — həyat dövrü məlumatlı müşahidə edilə bilən məlumat konteyneri. StateFlow — Kotlin Flow əsaslı LiveData-nın müasir əvəzi. SharedFlow — birdəfəlik hadisələr (naviqasiya, bildirişlər) üçün Hot Flow.

Data Binding və Two-Way Binding — Android-də UI və məlumatları birləşdirmə mexanizmləri. Data Binding XML-də əlaqəni bəyan edir; Two-Way Binding ViewModel-də sahəni avtomatik yeniləyir. Unidirectional Data Flow — məlumatların bir istiqamətdə axdığı prinsip: State → UI → Event → State. IT Sectr-də bütün yeni layihələrdə Unidirectional Data Flow-dan istifadə edirik — gözlənilməz vəziyyət dəyişikliklərindən yaranan xətaların sayını azaldır.