Mobil Rivojlanishda Arxitektura va Naqshlar: Bu Nima, Qanday Turlari Bor va Qanday Qo'llaniladi

Asosiy Arxitektura Naqshlari

Arxitektura naqshlari mas'uliyatlarning ilova sinflari o'rtasida qanday taqsimlanishini belgilaydi. Naqshni tanlash yangi ekranlar qo'shish va kodni sinash qulayligiga ta'sir qiladi.

MVC (Model-View-Controller)

MVC klassik naqsh bo'lib, unda Model ma'lumotlarni, View ko'rsatishni va Controller mantiqni boshqaradi. iOS da MVC standart (UIViewController); Android da Activity. Kamchilik shundaki, Controller ko'pincha "massiv" (Massive View Controller) bo'lib qoladi. iOS dasturchilari so'roviga (Reddit, 2025) ko'ra, 62% eski loyihalarda o'qib bo'lmaydigan kodning asosiy sababi sifatida MVCni ko'rsatadi.

MVP (Model-View-Presenter)

MVP Presenter Viewni interfeys orqali boshqarishi bilan farqlanadi, bu sinash qobiliyatini yaxshilaydi. MVP Jetpackdan oldin Androidda mashhur edi, ammo qulaylik jihatidan MVVMdan orqada.

MVVM (Model-View-ViewModel)

MVVM Google tomonidan Android va Apple tomonidan iOS uchun tavsiya etilgan naqshdir. ViewModel holatni saqlaydi va View Data Binding yoki @Published orqali o'zgarishlarga obuna bo'ladi. ViewModel Viewga bog'liq emas va sinash oson. IT Sectr da biz barcha loyihalarda asosiy naqsh sifatida MVVM dan foydalanamiz.

MVI va VIPER

MVI reaktiv naqsh bo'lib, unda har bir harakat Intent → Model → View siklini kuzatib boradi. MVI bashorat qilinadigan holatni kafolatlaydi. VIPER besh qatlamli (View, Interactor, Presenter, Entity, Router) iOS naqshidir, maksimal izolyatsiyani ta'minlaydi, lekin juda ko'p shablon kodni talab qiladi.

Clean Architecture

Clean Architecture Robert Martin kontseptsiyasi bo'lib, ilovani qatlamlarga ajratadi: tashqi qatlamlar (UI, DB, tarmoq) ichki qatlamlarga (biznes mantig'i, ob'ektlar) bog'liq. Mobil rivojlanishda Clean Architecture uch qatlamni o'z ichiga oladi: data (depolar), domain (Use Cases) va presentation (ViewModels, UI).

Repository Pattern Clean Architecture ning asosiy komponenti bo'lib, ma'lumot manbasini mavhumlashtiradi. Depo ma'lumotlarni tarmoqdan yoki mahalliy xotiradan (Room, Core Data) olishni hal qiladi va yagona formatni qaytaradi. Google (Architecture Guide, 2025) ga ko'ra, Repository Pattern tarmoq so'rovlari bo'lgan har qanday ilova uchun tavsiya etiladi. Clean Architecture 3–5 ekran va undan ko'p bo'lgan loyihalarda oqlanadi — oddiy ilovalar uchun MVVM dan boshlang.

Yaratuvchi Naqshlar

Singleton

Singleton bu sinfning yagona nusxasini kafolatlaydigan va unga global kirish nuqtasini ta'minlaydigan arxitektura naqshidir. Ma'lumotlar bazasi, sozlamalar menejeri va kesh uchun ishlatiladi. Kotlin da object orqali yaratiladi. Kamchilik — global holat tufayli sinashni murakkablashtiradi.

Factory va Builder

Factory ob'ekt yaratilishini fabrika usuliga topshiradi — new o'rniga fabrikaga murojaat qilasiz. Builder ko'p parametrlarga ega murakkab ob'ektlar (AlertDialog.Builder, NotificationCompat.Builder) uchun bosqichma-bosqich qurish naqshidir. Builder o'qish qulayligini yaxshilaydi va ob'ektlarni yig'ilgandan keyin o'zgarmas bo'lishiga imkon beradi.

Tarkibiy va Xulq-atvor Naqshlari

Adapter, Facade, Delegate, Protocol

Adapter bu bir sinfning interfeysini mijoz kutgan interfeysga o'zgartiradigan arxitektura naqshidir. Android da bu RecyclerView.Adapter. Facade murakkab tizimga soddalashtirilgan interfeysni ta'minlaydi — masalan, autentifikatsiya tafsilotlarini yashiradigan API uchun fasad. Delegate bu ob'ekt topshiriqni topshiradigan iOS naqshidir (UITableViewDelegate). Protocol Swift da interfeysning ekvivalentidir.

Observer va Strategy

Observer bu o'zgarishlarga obuna bo'lish naqshidir: sub'ekt obunachilarni yangilanishlar haqida xabardor qiladi. Mobil rivojlanishda Observer LiveData, StateFlow, RxJava va Combine ning asosidir. Strategy bu almashtiriladigan algoritmlar naqshidir: bir nechta if-else iboralarisiz turli strategiyani (saralash, tekshirish) ulaysiz.

Bog'liqlik Inyeksiyasi va Holat Boshqaruvi

Dependency Injection bu ob'ekt bog'liqliklarni o'zi yaratish o'rniga tashqaridan oladigan arxitektura naqshidir. new Database() o'rniga ma'lumotlar bazasini konstruktor orqali uzatasiz. DI sinashni soddalashtiradi — haqiqiy ma'lumotlar bazasi o'rniga Mock ishlatishingiz mumkin — va amalga oshirishlarni almashtirishni osonlashtiradi. Mashhur DI freymvorklari: Dagger va Hilt (Android), Swinject (iOS), Koin (Kotlin). Google tomonidan tavsiya etilgan Dagger ustidagi o'ram bo'lgan Hilt, DI sozlamalarini 3 baravar kamaytiradi.

Service Locator markaziy bog'liqlik reestriga ega DI muqobildir. Amalga oshirish osonroq, ammo u sinf bog'liqliklarini yashirib, sinashni qiyinlashtiradi. Zamonaviy loyihalar Hilt yoki Koin orqali DIni afzal ko'radi.

Flutter da Holat Boshqaruvi

Flutter da holat boshqaruvi o'z ekotizimidir. Redux — Actions → Reducer → State orqali o'zgarishlar bilan yagona Store. Google ning BLoC i Stream orqali hodisalar va holatlarni ajratadi. Provider — 2023 yilgacha Google tomonidan Flutter uchun tavsiya etilgan oddiy DI konteyneri. Riverpod — kompilyatsiya va sinash muammolarini hal qiladigan takomillashtirilgan Provider. GetX — marshrutlash, DI va holat boshqaruviga ega mikro-freymvork. Boshlang'ich Flutter dasturchilari uchun eng yaxshi hujjatlashtirilgan yechimlar sifatida Provider yoki Riverpod ni tavsiya qilamiz.

SOLID va DRY Tamoyillari

Muayyan naqshlardan tashqari, har qanday til va freymvorkda qo'llaniladigan umumiy arxitektura dizayn tamoyillari mavjud.

SOLID — ob'ektga yo'naltirilgan dizaynning besh tamoyili: Single Responsibility (bir sinf — bir vazifa), Open-Closed (kengaytirish uchun ochiq, o'zgartirish uchun yopiq), Liskov Substitution (pastki sinflar ota-sinfni almashtirishi mumkin), Interface Segregation (kichik interfeyslar), Dependency Inversion (abstraksiyalarga bog'liqlik). Mobil rivojlanishda SRP eng foydali tamoyildir: har bir sinf faqat bitta narsani qiladi. IT Sectr tajribasiga ko'ra, SRPni buzish tijoriy loyihalarda sinash muammolarining 70% ga sabab bo'ladi.

// Пример: нарушение 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 misoli to'rtta mas'uliyatga ega bo'lgan bitta UserManager sinfini har biri bitta mas'uliyatga ega to'rtta sinfga qanday aylantirishimizni ko'rsatadi. Bunday kodni sinash, o'zgartirish va qayta ishlatish osonroq.

DRY (Don't Repeat Yourself) — kod takrorlanishidan saqlaning. Takrorlanadigan mantiqni umumiy metodlar yoki sinflarga ajrating. KISS (Keep It Simple, Stupid) — soddalik nafislikdan muhimroqdir. YAGNI (You Aren't Gonna Need It) — kerak bo'lmasligi mumkin bo'lgan narsa uchun kod yozmang. Bu tamoyillar ortiqchaliksiz toza, saqlanishi oson kod yozishga yordam beradi.

Android Platforma Naqshlari

ViewModel (Android) UI holatini saqlash uchun Jetpack arxitektura komponenti, ekran aylanishiga chidamli. ViewModel Activity ga havolalarni o'z ichiga olmaydi va avtomatik tozalanadi. LiveData — hayot aylanishidan xabardor kuzatiladigan ma'lumot konteyneri. StateFlow — Kotlin Flowga asoslangan LiveData ning zamonaviy o'rnini bosuvchi. SharedFlow — bir martalik hodisalar (navigatsiya, bildirishnomalar) uchun Hot Flow.

Data Binding va Two-Way Binding — Android da UI va ma'lumotlarni bog'lash mexanizmlari. Data Binding XML da ulanishni e'lon qiladi; Two-Way Binding ViewModel dagi maydonni avtomatik yangilaydi. Unidirectional Data Flow — ma'lumotlar bir yo'nalishda oqadigan tamoyil: State → UI → Event → State. IT Sectr da biz barcha yangi loyihalarda Unidirectional Data Flow dan foydalanamiz — bu kutilmagan holat o'zgarishlaridan kelib chiqadigan xatolar sonini kamaytiradi.