SoC mobil inkişafda: bu nədir, prinsiplər və məsuliyyətin bölünməsi

SoC abreviaturası nə deməkdir

SoC Separation of Concerns — «məsuliyyətin bölünməsi» və ya «maraq sahələrinin ayrılması» mənasını verir. Proqramlaşdırma kontekstində concern termini hər hansı ayrıla bilən funksionallığı bildirir: istifadəçi interfeysinin göstərilməsi, kliklərin işlənməsi, məlumatların doğrulanması, şəbəkə əlaqəsi və ya baza ilə iş. SoC prinsipi kodu bu sahələr ətrafında qruplaşdırmağı əmr edir ki, birindəki dəyişikliklər digərlərinə təsir etməsin.

SoC abreviaturası texniki ədəbiyyatda, memarlıq müzakirələrində və freymvork sənədlərində geniş istifadə olunur. Məsələn, Android Architecture Components sənədlərində ViewModel və View-in ayrılması üçün motivasiya kimi SoC dəfələrlə qeyd olunur. iOS icmasında bu termin Massive View Controller problemini — SoC-nin olmamasının birbaşa nəticəsini müzakirə edərkən istifadə olunur.

Anlamaq vacibdir ki, SoC birdəfəlik hərəkət deyil, davamlı bir prosesdir. Tətbiq böyüdükcə yeni məsuliyyət sahələri yaranır və memarlığı yenidən nəzərdən keçirmək lazım gəlir. Yaxşı kod bazası hər bir concern-in izolə edildiyi və idarə oluna bildiyi sabit vəziyyətə çatana qədər bir neçə bölmə iterasiyasından keçir.

SoC vs Separation of Concerns

Separation of Concerns və onun SoC abreviaturası eyni prinsipi ifadə edir. Fərq yalnız istifadə kontekstindədir: tam ad rəsmi sənədlərdə, tədris materiallarında və konsepsiyanı yeni tərtibatçılara ilk dəfə izah edərkən işlənir. SoC texniki müzakirələrdə, kod icmalında və qısalığın vacib olduğu sənədlərdə rahatdır.

Peşəkar mühitdə hər iki termin bir-birini əvəz edə bilər. Tərtibatçı «burada SoC pozulub» və ya «bu Separation of Concerns-i pozur» deyə bilər — məna dəyişmir. Lakin vakansiyalarda və memarlıq tələblərində daha çox tam ad, çatlarda və kod icmalında isə abreviatura işlənir. Hər iki variantı bilmək sənayeyə rahat daxil olmaq üçün vacibdir.

Terminoloji qarışıqlıq mövcuddur: SoC abreviaturası həmçinin aparat kontekstində System-on-a-Chip (çip üzərində sistem) üçün istifadə olunur. Mobil inkişafda kontekst həmişə ətraf mühitdən aydındır — əgər müzakirə kod memarlığına aiddirsə, söhbət Separation of Concerns-dən gedir. Bu məqalədə SoC hər yerdə məsuliyyətin bölünməsi prinsipinə aiddir.

SoC mobil memarlıqda necə tətbiq olunur

Üçqatlı memarlıq — mobil tətbiqlərdə SoC-nin həyata keçirilməsinin ən geniş yayılmış üsulu. Kodu Presentation (UI), Domain (biznes məntiqi) və Data (mənbələrlə iş) hissələrinə ayırır. Hər bir qat ciddi müəyyən edilmiş sinif növlərini ehtiva edir və interfeyslər vasitəsilə qonşulardan izolə edilir. Bu yanaşma iOS, Android və Flutter layihələri üçün eyni dərəcədə effektivdir.

Presentation qatı və ViewModel

View və ViewModel təqdimat qatını təşkil edir. View interfeysin göstərilməsinə və istifadəçi hadisələrinin ötürülməsinə cavabdehdir. ViewModel ekran vəziyyətini saxlayır və Domain qatından alınan məlumatları göstərməyə hazır formata çevirir. ViewModel Activity, Fragment və ya UIViewController-ə istinad saxlamır — bu, UI və məntiq arasında SoC-ni təmin edir.

Məsələn, Android Jetpack-də ViewModel ekranın fırlanmasından sonra da qalır, UI isə yenidən yaradılır. SoC olmadan vəziyyəti Activity-də saxlamaq, həyat dövrünün idarə edilməsini məlumatlarla qarışdırmaq lazım gələrdi. ViewModel bu tapşırığı izolə şəkildə həll edir, məsuliyyətin bölünməsi prinsipinin təmiz tətbiqini nümayiş etdirir.

Domain qatı və Use Cases

Use Cases platformadan asılı olmayan biznes qaydalarını ehtiva edir. Bu qat Android SDK, iOS UIKit və ya Flutter framework-ü import etmir. Use Case Repository-dən məlumat alır, onlara biznes məntiqini tətbiq edir və nəticəni qaytarır. SoC sayəsində bir Use Case müxtəlif ekranlarda və platformalarda təkrar istifadə edilə bilər.

Klassik nümunə — qeydiyyat forması üçün ValidateAndSaveUseCase. O, email və şifrənin düzgünlüyünü yoxlayır, saxlamaq üçün UserRepository-i çağırır və ValidationResult qaytarır. Nə UI, nə də verilənlər bazası valide etmə qaydalarını bilmir — onlar bir yerdə cəmlənib, bu da onların dəyişdirilməsini asanlaşdırır.

Data qatı və Repository

Repository məlumat mənbələrini tətbiqin qalan hissəsindən abstraksiyalaşdırır. ViewModel məlumatların haradan gəldiyini bilmir — REST API, GraphQL, yerli verilənlər bazası və ya keş. Repository hansı mənbədən istifadə edəcəyinə qərar verir və bu məntiqi interfeys arxasında gizlədir. Bu, məlumatların əldə edilməsi ilə onların istehlakı arasında SoC-dir.

DataSource daha da dərin bölünmə təmin edir: RemoteDataSource yalnız HTTP sorğularına, LocalDataSource isə Room, CoreData və ya SharedPreferences ilə işə cavabdehdir. Repository onları birləşdirərək keşləmə strategiyalarını tətbiq edir. Hər bir DataSource müstəqil şəkildə dəyişdirilə bilər ki, bu da serverlər və ya verilənlər bazaları arasında miqrasiya zamanı kritik əhəmiyyət daşıyır.

Belə çoxsəviyyəli DataSource sistemi SoC-ni infrastruktur səviyyəsində həyata keçirir: şəbəkə əlaqəsi, yerli saxlama və keşləmə — hər biri öz məntiqi və həyat dövrü olan ayrıca concerns. HTTP müştərisi dəyişdirilərkən yalnız RemoteDataSource dəyişir, Repository və yuxarı qatlar isə toxunulmaz qalır ki, bu da məsuliyyətin bölünməsinin praktiki dəyərini təsdiqləyir.

SoC memarlıq nümunələrində

MVP (Model-View-Presenter) — mobil inkişafda SoC-ni açıq şəkildə həyata keçirən ilk nümunələrdən biridir. Presenter məntiqi ehtiva edir və View-i interfeys vasitəsilə idarə edir. View passivdir — yalnız Presenter-in dediklərini göstərir. Bölünmə testləri asanlaşdırır: Presenter emulator olmadan test edilir, View isə o qədər sadə qalır ki, orada heç nə sınmır.

MVVM reaktiv bağlama əlavə etdi: View Observable və ya StateFlow vasitəsilə ViewModel-in dəyişikliklərinə abunə olur. ViewModel View-ə istinad saxlamır ki, bu da yaddaş sızması riskini aradan qaldırır və concerns-ləri daha da güclü ayırır. Android-də MVVM Jetpack ViewModel və LiveData sayəsində, iOS-da isə Combine və RxSwift sayəsində standart halına gəldi.

Clean Architecture Robert Martin SoC-ni radikal halqalara bölünməyə çatdırır. Xarici halqa (freymvorklar və drayverlər) daxili halqadan (entity) asılıdır, əksinə deyil. Praktikada mobil layihələr nadir hallarda dörd halqanın hamısını həyata keçirir — Presentation ətrafında Domain və Data qatları kifayətdir. Lakin «daxilə» asılılıq prinsipi freymvorkları dəyişdirərkən əhəmiyyətli üstünlüklər verir.

// View — yalnız göstərmə, məntiqsiz
final class LoginViewController: UIViewController {
    let viewModel: LoginViewModel

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

// ViewModel — ekran məntiqini ehtiva edir, UIKit-i bilmir
final class LoginViewModel {
    private let loginUseCase: LoginUseCase

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

// Use Case — biznes məntiqi, platformadan asılı deyil
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)
    }
}

Nümunə üç SoC səviyyəsini göstərir: LoginViewController yalnız hadisələri ötürür, LoginViewModel vəziyyəti idarə edir, LoginUseCase biznes qaydalarını ehtiva edir. Hər bir sinif müstəqil test edilir və UI freymvorkunun dəyişdirilməsi Use Case-ə təsir etmir.

Mobil layihələrdə SoC-nin tipik pozulmaları

Massive View Controller — iOS-da SoC-nin ən çox rast gəlinən pozulması. UI-ni idarə edən, şəbəkə sorğularını emal edən, JSON-u pars edən və məlumatları saxlayan sinif prinsipi bütün səviyyələrdə pozur. Həll — hər bir məsuliyyəti ayrıca komponentə çıxarmaq: NetworkingService, JSONParser, CoreDataStack, ViewController-ə yalnız View-in idarə edilməsini buraxmaq.

Android-də analoji problem — God Activity və ya God Fragment. Məlumatları yükləyən, formaları valide edən, dialoqları göstərən və UI-ni yeniləyən bir aktivlik. Müalicəsi — ViewModel və Repository tətbiq etmək, onlar vəziyyət və məlumatların idarəsini öz üzərinə götürür. ViewModel həmçinin məlumatların ekran fırlanması zamanı itirilməsindən qoruyur.

Üçüncü pozulma — platforma və biznes kodunun qarışdırılması. Məsələn, HTTP sorğusunu birbaşa SwiftUI View və ya Android Composable-də yerləşdirmək. Bu kodu daşınmaz və test etməyi çətin edir. Düzgün yanaşma — sorğunu Repository-ə çıxarmaq, Use Case vasitəsilə çağırmaq, View isə yalnız nəticəyə abunə olur. Sistemin hər bir elementi öz tapşırığını həll edir və onun sərhədlərindən kənara çıxmır.