SoC mobil ishlab chiqishda: bu nima, prinsiplar va mas'uliyat taqsimoti

SoC qisqartmasi nimani anglatadi

SoC Separation of Concerns — «mas'uliyat taqsimoti» yoki «qiziqish sohalarini ajratish» degan ma'noni anglatadi. Dasturlash kontekstida concern atami har qanday ajratiladigan funksionallikni bildiradi: foydalanuvchi interfeysini ko'rsatish, bosishlarni qayta ishlash, ma'lumotlarni tekshirish, tarmoq aloqasi yoki baza bilan ishlash. SoC prinsipi kodni ushbu sohalar atrofida guruhlashni buyuradi, shunda biridagi o'zgarishlar boshqalariga ta'sir qilmaydi.

SoC qisqartmasi texnik adabiyotlarda, arxitektura munozaralarida va freymvork hujjatlarida keng qo'llaniladi. Masalan, Android Architecture Components hujjatlarida ViewModel va Viewni ajratish uchun motivatsiya sifatida SoC bir necha bor eslatib o'tilgan. iOS hamjamiyatida bu atama Massive View Controller muammosini — SoC yo'qligining bevosita natijasini muhokama qilishda ishlatiladi.

Shuni tushunish muhimki, SoC bir martalik harakat emas, balki doimiy jarayondir. Ilova o'sib borishi bilan yangi mas'uliyat sohalari paydo bo'ladi va arxitektura qayta ko'rib chiqilishi kerak. Yaxshi kod bazasi har bir concern izolyatsiya qilingan va boshqariladigan barqaror holatga erishgunga qadar bir necha bo'linish iteratsiyalaridan o'tadi.

SoC vs Separation of Concerns

Separation of Concerns va uning SoC qisqartmasi bir xil prinsipni ifodalaydi. Farq faqat foydalanish kontekstida: to'liq nom rasmiy hujjatlarda, o'quv materiallarida va kontseptsiyani yangi dasturchilarga birinchi marta tushuntirishda qo'llaniladi. SoC texnik munozaralarda, kod ko'rib chiqishda va qisqalik muhim bo'lgan hujjatlarda qulaydir.

Professional muhitda ikkala atama bir-birini almashtirishi mumkin. Dasturchi «bu yerda SoC buzilgan» yoki «bu Separation of Concernsni buzadi» deyishi mumkin — ma'no o'zgarmaydi. Biroq, ish e'lonlarida va arxitektura talablarida ko'pincha to'liq nom, chat va kod ko'rib chiqishda esa qisqartma ishlatiladi. Ikkala variantni bilish sanoatga qulay kirish uchun zarurdir.

Terminologik chalkashlik mavjud: SoC qisqartmasi apparat kontekstida System-on-a-Chip (chipdagi tizim) uchun ham ishlatiladi. Mobil ishlab chiqishda kontekst har doim atrof-muhitdan aniq — agar munozara kod arxitekturasiga tegishli bo'lsa, gap Separation of Concerns haqida ketadi. Ushbu maqolada SoC hamma joyda mas'uliyat taqsimoti prinsipiga tegishli.

SoC mobil arxitekturada qanday qo'llaniladi

Uch qatlamli arxitektura — mobil ilovalarda SoCni amalga oshirishning eng keng tarqalgan usuli. Kodni Presentation (UI), Domain (biznes mantiq) va Data (manbalar bilan ishlash) ga ajratadi. Har bir qatlam qat'iy belgilangan sinf turlarini o'z ichiga oladi va interfeyslar orqali qo'shnilardan izolyatsiya qilinadi. Ushbu yondashuv iOS, Android va Flutter loyihalari uchun bir xil darajada samaralidir.

Presentation qatlami va ViewModel

View va ViewModel taqdimot qatlamini tashkil qiladi. View interfeysni ko'rsatish va foydalanuvchi hodisalarini uzatish uchun javobgardir. ViewModel ekran holatini saqlaydi va Domain qatlamidan olingan ma'lumotlarni ko'rsatishga tayyor formatga aylantiradi. ViewModel Activity, Fragment yoki UIViewControllerga havolaga ega emas — bu UI va mantiq o'rtasida SoCni ta'minlaydi.

Masalan, Android Jetpack da ViewModel ekran aylanishidan omon qoladi, UI esa qayta yaratiladi. SoC bo'lmasa, holatni Activityda saqlash, hayot tsiklini boshqarishni ma'lumotlar bilan aralashtirish kerak bo'lardi. ViewModel bu vazifani izolyatsiya qilingan holda hal qiladi, mas'uliyat taqsimoti prinsipining sof amalga oshirilishini namoyish etadi.

Domain qatlami va Use Cases

Use Cases platformadan mustaqil biznes qoidalarini o'z ichiga oladi. Bu qatlam Android SDK, iOS UIKit yoki Flutter frameworkni import qilmaydi. Use Case Repositorydan ma'lumot oladi, ularga biznes mantiqini qo'llaydi va natijani qaytaradi. SoC tufayli bitta Use Case turli ekranlar va platformalarda qayta ishlatilishi mumkin.

Klassik misol — ro'yxatdan o'tish formasi uchun ValidateAndSaveUseCase. Elektron pochta va parolning to'g'riligini tekshiradi, saqlash uchun UserRepositoryni chaqiradi va ValidationResult qaytaradi. Na UI, na ma'lumotlar bazasi tekshirish qoidalarini bilmaydi — ular bir joyda jamlangan, bu ularni o'zgartirishni osonlashtiradi.

Data qatlami va Repository

Repository ma'lumot manbalarini ilovaning qolgan qismidan abstraktsiyalashtiradi. ViewModel ma'lumotlarning qayerdan kelishini bilmaydi — REST API, GraphQL, mahalliy ma'lumotlar bazasi yoki kesh. Repository qaysi manbadan foydalanishni hal qiladi va bu mantiqni interfeys orqasida yashiradi. Bu ma'lumot olish va uni iste'mol qilish o'rtasidagi SoCdir.

DataSource yanada chuqurroq bo'linishni ta'minlaydi: RemoteDataSource faqat HTTP so'rovlari uchun, LocalDataSource — Room, CoreData yoki SharedPreferences bilan ishlash uchun javobgardir. Repository ularni birlashtirib, keshlash strategiyalarini qo'llaydi. Har bir DataSource mustaqil ravishda almashtirilishi mumkin, bu serverlar yoki ma'lumotlar bazalari o'rtasida migratsiyada juda muhimdir.

Bunday ko'p darajali DataSource tizimi SoCni infratuzilma darajasida amalga oshiradi: tarmoq aloqasi, mahalliy saqlash va keshlash — har biri o'z mantiqi va hayot tsikliga ega alohida concerns. HTTP mijozini o'zgartirishda faqat RemoteDataSource o'zgaradi, Repository va yuqori qatlamlar esa o'zgarishsiz qoladi, bu mas'uliyat taqsimotining amaliy qiymatini tasdiqlaydi.

SoC arxitektura naqshlarida

MVP (Model-View-Presenter) — mobil ishlab chiqishda SoCni aniq amalga oshiruvchi birinchi naqshlardan biri. Presenter mantiqni o'z ichiga oladi va Viewni interfeys orqali boshqaradi. View passiv — faqat Presenter aytgan narsani ko'rsatadi. Bo'linish testlashni osonlashtiradi: Presenter emulatorsiz sinovdan o'tkaziladi, View esa shunchalik soddaki, unda hech narsa buzilmaydi.

MVVM reaktiv bog'lanishni qo'shdi: View Observable yoki StateFlow orqali ViewModel o'zgarishlariga obuna bo'ladi. ViewModel Viewga havolani saqlamaydi, bu xotira oqish xavfini bartaraf qiladi va concernslarni yanada kuchliroq ajratadi. Androidda MVVM Jetpack ViewModel va LiveData tufayli, iOSda esa Combine va RxSwift tufayli standartga aylandi.

Clean Architecture Robert Martin SoCni halqalarga radikal bo'linishgacha olib boradi. Tashqi halqa (freymvorklar va drayverlar) ichki (entitilar) ga bog'liq, aksincha emas. Amalda mobil loyihalar kamdan-kam hollarda to'rtta halqaning barchasini amalga oshiradi — Presentation atrofida Domain va Data qatlamlari etarli. Ammo «ichkariga» bog'liqlik prinsipi freymvorklarni o'zgartirishda sezilarli ustunliklarni beradi.

// View — faqat ko'rsatish, mantiqsiz
final class LoginViewController: UIViewController {
    let viewModel: LoginViewModel

    func loginTapped() {
        viewModel.login(emailField.text, passwordField.text)
    }
}

// ViewModel — ekran mantiqini o'z ichiga oladi, UIKitni bilmaydi
final class LoginViewModel {
    private let loginUseCase: LoginUseCase

    func login(email: String?, password: String?) {
        loginUseCase.execute(email, password)
    }
}

// Use Case — biznes mantiq, platformaga bog'liq emas
final class LoginUseCase {
    private let repo: AuthRepository

    func execute(email: String?, password: String?) {
        guard let e = email, let p = password else { return }
        repo.authenticate(e, p)
    }
}

Misol uch SoC darajasini ko'rsatadi: LoginViewController faqat hodisalarni uzatadi, LoginViewModel holatni boshqaradi, LoginUseCase biznes qoidalarini o'z ichiga oladi. Har bir sinf mustaqil sinovdan o'tkaziladi va UI freymvorkini almashtirish Use Casega ta'sir qilmaydi.

Mobil loyihalarda SoCning tipik buzilishlari

Massive View Controller — iOSda SoCning eng keng tarqalgan buzilishi. UI ni boshqaradigan, tarmoq so'rovlarini qayta ishlaydigan, JSONni tahlil qiladigan va ma'lumotlarni saqlaydigan sinf prinsipni barcha darajalarda buzadi. Yechim — har bir mas'uliyatni alohida komponentga chiqarish: NetworkingService, JSONParser, CoreDataStack, ViewControllerga faqat Viewni boshqarishni qoldirish.

Android da shunga o'xshash muammo — God Activity yoki God Fragment. Ma'lumotlarni yuklaydigan, formalarni tekshiradigan, dialoglarni ko'rsatadigan va UI ni yangilaydigan bitta faoliyat. Davosi — ViewModel va Repository joriy etish, ular holat va ma'lumotlarni boshqarishni o'z zimmasiga oladi. ViewModel shuningdek ma'lumotlarni ekran aylanishida yo'qotilishdan himoya qiladi.

Uchinchi buzilish — platforma va biznes kodini aralashtirish. Masalan, HTTP so'rovini to'g'ridan-to'g'ri SwiftUI View yoki Android Composable ichida joylashtirish. Bu kodni ko'chirib bo'lmaydigan va testlash qiyin bo'lgan holga keltiradi. To'g'ri yondashuv — so'rovni Repositoryga chiqarish, u Use Case orqali chaqiriladi, View esa faqat natijaga obuna bo'ladi. Tizimning har bir elementi o'z vazifasini hal qiladi va uning chegaralaridan tashqariga chiqmaydi.