Separation of Concerns mobil inkişafda — bu nədir, prinsiplər və tətbiqi

Separation of Concerns nədir

Separation of Concerns — proqram sisteminin hər biri bir tapşırığı həll edən müstəqil hissələrə parçalanması prinsipidir. Concern (məsuliyyət sahəsi) termini funksionallığın ayrıla bilən hər hansı hissəsini bildirir: ekranın göstərilməsi, klikin işlənməsi, məlumatların validasiyası və ya şəbəkə əlaqəsi. Prinsip kodu elə qruplaşdırmağı əmr edir ki, bir sahədəki dəyişikliklər digərlərində dəyişiklik tələb etməsin.

Mobil inkişafda SoC bir neçə səviyyədə özünü göstərir: tətbiqin ekranlara bölünməsindən tutmuş bir sinif daxilində kodun təşkilinə qədər. Eyni anda şəbəkədən məlumat yükləyən, JSON parse edən və UI çəkən Activity və ya ViewController Separation of Concerns-i pozur — belə kodu saxlamaq, test etmək və genişləndirmək çətindir. Alternativ — hər bir məsuliyyət növünü ayrıca komponentə çıxarmaqdır.

Prinsip abstraksiya anlayışı ilə sıx bağlıdır: hər təbəqə ciddi müəyyən edilmiş interfeys təqdim edir və tətbiq detallarını gizlədir. Bunun sayəsində tərtibatçı şəbəkə kitabxanasını və ya verilənlər bazasını UI məntiqini yenidən yazmadan dəyişə bilər. Bu, tələblərin və texnologiyaların zamanla dəyişdiyi uzunömürlü layihələrdə xüsusilə dəyərlidir.

Prinsipin tarixi və mənşəyi

Edsger Dijkstra Separation of Concerns ideyasını ilk dəfə 1974-cü ildə “On the Role of Scientific Thought” məqaləsində formalaşdırmışdır. O, proqram sistemlərinin mürəkkəbliyini onları təcrid olunmuş şəkildə təhlil edilən hissələrə bölməklə idarə etmək olar deyə mübahisə etmişdir. Bu yanaşma o dövrün kodun hesablamaları, giriş-çıxışı və istifadəçi interfeysini qarışdırdığı monolit proqramları ilə ziddiyyət təşkil edirdi.

1980-ci illərdə ideyanı struktur proqramlaşdırma tərəfdarları, daha sonra isə obyekt yönümlü yanaşma inkişaf etdirmişdir. Smalltalk və C++ kimi dillər inkapsulyasiya və modulluq mexanizmləri təmin etmiş, bu da SoC-i praktik alətə çevirmişdir. Müasir arxitektura nümunələri — MVC, MVP, MVVM və Clean Architecture — Separation of Concerns prinsipinin birbaşa təcəssümüdür.

Mobil inkişaf dünyasında Apple MVC-ni iOS üçün standart olaraq təbliğ edirdi, burada Model-View-Controller məlumatları, göstərməni və idarəetmə məntiqini ayırır. Google Android üçün ViewModel və Repository-ə əsaslanan arxitektura tövsiyələri təklif etmişdir — hər komponent öz dar tapşırığını həll edir. SoC olmadan mobil tətbiqlər Massive View Controller-a — minlərlə sətirdən ibarət siniflərə çevrilir, burada hər hansı dəyişiklik bütün funksionallığı poza bilər.

Mobil arxitekturada bölgü səviyyələri

Dörd əsas təbəqə Separation of Concerns-i həyata keçirən tipik mobil tətbiq arxitekturasını təşkil edir. Hər təbəqə yalnız öz sahəsinə cavabdehdir və qonşuları ilə interfeyslər vasitəsilə əlaqə qurur.

UI təbəqəsi: View və ViewModel

View yalnız məlumatların göstərilməsi və istifadəçi hadisələrinin işlənməsi üçün cavabdehdir. iOS-da bu UIViewController və UIView, Android-də — Fragment və ya Activity-dir. ViewModel ekranın vəziyyətini və məlumatların göstərilməyə hazır formata çevrilməsi məntiqini ehtiva edir. Bölgü UIKit-in SwiftUI ilə əvəz edilməsinin və ya ekranın Jetpack Compose-a yenidən yazılmasının biznes məntiqinə təsir etməyəcəyinə zəmanət verir.

ViewModel-in test edilməsi emulator və ya simulyatorun işə salınmasını tələb etmir — məlumatların çevrilməsini və istifadəçi hərəkətlərinə reaksiyanı yoxlayan vahid testlər kifayətdir. Bu, Separation of Concerns-in birbaşa nəticəsidir: UI biznes qaydaları ilə qarışmır və hər komponent təcrid olunmuş şəkildə test edilir.

Biznes məntiqi təbəqəsi: Use Cases və Interactors

Use Case (və ya Interactor) tətbiqin biznes qaydalarını — hesablamaları, yoxlamaları, məlumatlara zənglərin orkestrasiyasını ehtiva edir. Bu təbəqə UI və platforma freymvorklarının mövcudluğundan xəbərsizdir. Use Case məlumatları Repository-dən alır, onlara məntiq tətbiq edir və hazır nəticəni ViewModel-ə qaytarır. Bölgü bir Use Case-in müxtəlif ekranlarda təkrar istifadəsinə imkan verir.

Məsələn, LoginUseCase email-in düzgünlüyünü yoxlayır, autentifikasiya üçün AuthRepository-i çağırır və nəticəni qaytarır. O, giriş ekranının necə görünməsindən — SwiftUI, UIKit və ya Compose-dan asılı deyil. Biznes qaydaları dəyişərsə, UI və verilənlər bazasına toxunmadan bir Use Case-i dəyişmək kifayətdir.

Məlumat təbəqəsi: Repository və DataSource

Repository məlumat mənbələrini abstraksiya edir: uzaq API, yerli verilənlər bazası və ya yaddaşda keş. ViewModel və Use Case məlumatların dəqiq haradan gəldiyini bilmir — Repository şəbəkədən və ya keşdən yükləməyə qərar verir. Bu bölgü saxlama tətbiqini biznes məntiqinə və UI-ə təsir etmədən dəyişməyə imkan verir.

DataSource daha da aşağı səviyyəli bölgüdür: NetworkDataSource yalnız HTTP sorğularına, LocalDataSource isə Room və ya CoreData ilə işə cavabdehdir. Repository müxtəlif DataSource-lərə zəngləri vahid ardıcıl interfeysdə birləşdirir. Hər DataSource mock və ya saxta serverlər vasitəsilə müstəqil test edilir.

DataSource təbəqəsinin düzgün tətbiqi verilənlər bazası sxeminin dəyişdirilməsinin və ya REST API-nin GraphQL ilə əvəz edilməsinin yalnız bir DataSource-ə təsir edəcəyinə, lakin Repository və ya onun istehlakçılarına təsir etməyəcəyinə zəmanət verir. Bu, infrastruktur səviyyəsində Separation of Concerns-in birbaşa nəticəsidir: hər bir technical concern təcrid olunub və kaskad dəyişikliklər olmadan əvəz edilə bilər.

Dizayn nümunələrində SoC

MVVM (Model-View-ViewModel) — mobil inkişaf üçün ən məşhur nümunə, birbaşa Separation of Concerns-i həyata keçirir. Model məlumatları və biznes məntiqini ehtiva edir, View göstərməyə cavabdehdir, ViewModel isə onları reaktiv mexanizmlər vasitəsilə birləşdirir. Flutter-da analoji rolu hadisələrə, vəziyyətlərə və biznes məntiqinə bölünmə ilə BLoC oynayır.

Clean Architecture Robert Martin (Uncle Bob) SoC-i maksimuma çatdırır: sistem müstəqil halqalara bölünür — varlıqlar, use cases, adapterlər və freymvorklar. Daxili halqalar (varlıqlar) xarici halqalardan (freymvorklardan) asılı deyil. Bu, verilənlər bazasını, UI freymvorkunu və hətta platformanı tətbiqin core məntiqini yenidən yazmadan dəyişməyə imkan verir.

Praktikada mobil layihələr nadir hallarda tam Clean Architecture-i həyata keçirir — əksər tətbiqlər üçün üçtəbəqəli arxitektura kifayətdir: UI, Domain və Data. Domain təbəqəsi Use Cases və biznes modellərini ehtiva edir və Android SDK və ya iOS SDK-dan tamamilə təcrid olunub. Belə bölgü 20% səylə 80% fayda verir.

// Data layer — yalnız məlumatların alınmasına cavabdehdir
class UserRepository(private val api: UserApi) {
    suspend fun getUser(id: String): User = api.fetchUser(id)
}

// Domain layer — biznes məntiqi, API və ya bazanı bilmir
class GetUserNameUseCase(
    private val repo: UserRepository
) {
    suspend fun invoke(id: String): String {
        val user = repo.getUser(id)
        return "${user.firstName} ${user.lastName}"
    }
}

// UI layer — yalnız göstərmə
class UserViewModel(
    private val getUserName: GetUserNameUseCase
) {
    fun onUserLoaded(id: String) {
        viewModelScope.launch {
            _name.value = getUserName.invoke(id)
        }
    }
}

Yuxarıdakı kod təmiz bölgünü nümayiş etdirir: UserRepository yalnız API ilə işləyir, GetUserNameUseCase adın formatlanması biznes məntiqini ehtiva edir, UserViewModel isə UI vəziyyətini idarə edir. Hər sinfin dəyişmək üçün bir səbəbi var, bu da Separation of Concerns-in mahiyyətidir.

Separation of Concerns-in üstünlükləri və məhdudiyyətləri

SoC-in əsas üstünlüyü — saxlanıla bilənlikdir. Müstəqil təbəqələrə bölünmüş kodu təhlil etmək asandır: tərtibatçı yalnız xətanın baş verdiyi təbəqəyə baxır və qalanlarına fikrini yayındırmır. Uzunmüddətli layihələrdə bu, monolit kodla müqayisədə xətaların axtarışı və düzəldilməsi vaxtını 30–50% azaldır.

İkinci mühüm üstünlük — test edilə bilənlikdir. Biznes məntiqi UI və freymvorklardan təcrid olunduqda, emulatoru işə salmadan vahid testlərlə əhatə olunur. Yüksək vahid test əhatəsi olan Android və iOS layihələri yeni funksiyalar əlavə edərkən əhəmiyyətli dərəcədə daha az reqressiyaya malikdir.

Əsas məhdudiyyət — mürəkkəbliyin artması. Mikrotəbəqələrə və abstraksiyalara həddindən artıq bölgü sadə düymə əlavə etmək üçün tərtibatçının beş faylı düzəltməsinə gətirib çıxarır. Separation of Concerns prinsipi ağıllı balans tələb edir: yalnız həqiqətən müstəqil dəyişən sahələri bölmək. Kiçik layihələr üçün əlavə abstraksiyalar olmadan əsas UI, məntiq və məlumat bölgüsü kifayətdir.