SRP: bu nədir, tək məsuliyyət prinsipi inkişafda

SRP (Single Responsibility Principle) nədir?

SRP (Single Responsibility Principle) — tək məsuliyyət prinsipi olub müəyyən edir: hər bir sinif və ya modulun dəyişməsi üçün yalnız bir səbəbi olmalıdır. Bu o demək deyil ki, sinif yalnız bir əməliyyat yerinə yetirməlidir. Söhbət bir aktyor qarşısında bir məsuliyyətlə birləşdirilmiş əlaqəli hərəkətlər qrupundan gedir.

Robert Martin SRP-ni aktyorlar baxımından yenidən formullaşdırdı: sinif yalnız bir maraqlı şəxsin və ya bir qrup insanın tələbi ilə dəyişməlidir. Əgər iki fərqli aktyor bir sinfin dəyişməsini tələb edirsə — məsuliyyət düzgün bölünməmişdir.

Məsələn, eyni anda həm maaşı hesablayan (mühasibatlığın tələbi) həm də hesabat hazırlayan (rəhbərliyin tələbi) Employee sinfi SRP-ni pozur. Hesablama qaydalarının dəyişməsi hesabatın hazırlanmasına təsir edə bilər və əksinə.

SRP-nin formal tərifi

Modul dəyişmək üçün bir və yalnız bir səbəbə malik olmalıdır. Dəyişiklik səbəbi tələbi irəli sürən aktyor — şəxs və ya sistem tərəfindən müəyyən edilir. Əgər müxtəlif aktyorlardan gələn tələblər bir modulun dəyişməsinə səbəb olarsa — modul SRP-ni pozur.

Aktyor konsepsiyası SRP-ni abstrakt tövsiyə deyil, arxitektura analizinin praktik alətinə çevirir. Sistemi layihələndirərkən sual vermək kifayətdir: «Bu kodu kim dəyişməyi xahiş edəcək?» — əgər cavabda birdən çox maraqlı şəxs varsa, məsuliyyət bölünməlidir.

Tək məsuliyyət prinsipi necə işləyir

Tək məsuliyyət bir səbəbdən dəyişən metodların qruplaşdırılması ilə həyata keçirilir. Sinif əlaqəli məntiqin «toplanma nöqtəsi» olur, hər şey üçün «isveçrə bıçağı» yox. Bu kodu başa düşməyi asanlaşdırır: tərtibatçı sinfi görür və onun təyinatını dərhal anlayır.

SRP-nin iş mexanizmi bir dəyişiklik oxu qaydasına əsaslanır. Əgər funksionallıq müstəqil səbəblərdən dəyişə bilərsə — ayrı siniflərə çıxarılmalıdır. Bu siniflər arasında əlaqələr kompozisiya və ya delegasiya vasitəsilə qurulur.

SRP pozuntusu müxtəlif məlumatlarla işləyən onlarla metodu olan «tanrı sinifləri»ndə (God Objects) özünü göstərir. Belə sinfi test etmək çətindir — bir metodun testi qalanların hamısı üçün mühitin qurulmasını tələb edir. Bir məsuliyyətin dəyişməsi digərini poza bilər, bu da kodu kövrək edir.

Praktikada SRP tərtibatçılara «bu kod haradadır?» sualına cavab verməyə kömək edir. Əgər hər məsuliyyət öz sinfinə ayrılıbsa, lazımi faylı tapmaq saniyələr çəkir. MVVM arxitekturası olan Android layihəsində bu o deməkdir ki, UserViewModel yalnız istifadəçi ekranının vəziyyətinə cavabdehdir, UserRepository isə məlumatların alınmasına. Keşləmə məntiqini axtaran tərtibatçı ViewModel-ə deyil, UserCacheRepository-ə gedir. Kodun belə təşkili yeni komanda üzvlərinin onboardingini sürətləndirir və refaktorinq zamanı səhvlərin sayını azaldır.

SRP mobil inkişafda nə üçün vacibdir

Mobil inkişaf kodun modulluğuna xüsusi tələblər qoyur. Android Fragment və ya iOS ViewController çox vaxt məntiqin «cazibə nöqtəsi»nə çevrilir: kliklərin işlənməsi, API çağırışı, cavabın pars edilməsi, UI-nin yenilənməsi — hamısı bir sinifdə. SRP bu vəzifələrin ayrılmasını tələb edir.

Android arxitekturasında SRP Google-ın Jetpack tövsiyələrinə daxil edilmişdir: ViewModel ekranın vəziyyətinə, Repository məlumatlara, UseCase biznes məntiqinə cavabdehdir. Hər komponentin dəyişməsi üçün bir səbəbi var. iOS inkişafında MVVM və Coordinator pattern-ləri eyni məntiqə əməl edir.

Mobil layihələrdə SRP-yə riayət etmək ölçülə bilən üstünlüklər verir: siniflərin ölçüsünün 40-60% azalması, kod-review vaxtının qısalması və yeni funksionallıq əlavə edildikdə reqressiv səhvlərin sayının azalması. Izolyasiya olunmuş modullar unit-testlərlə əhatə etmək və digər ekranlarda təkrar istifadə etmək üçün daha asandır.

SRP-nin testləşdirməyə təsiri

Unit-testlər SRP-yə riayət edən siniflər üçün daha az mock-obyekt və quraşdırma tələb edir. Əgər sinfin bir məsuliyyəti varsa, onun asılılıqları məhduddur. Test bir davranışı yoxlayır, bir neçə əlaqəsiz ssenarinin kombinasiyasını yox.

Google Testing Blog (2023) hesabatına görə, tək məsuliyyətli siniflər aqreqator siniflərlə müqayisədə 35% daha çox test əhatəsi göstərir. Tərtibatçılar kiçik, başa düşülən modullar üçün daha həvəslə test yazırlar.

Android və iOS-da SRP nümunələri

Tipik SRP-ni pozan Android sinfini nəzərdən keçirək — o həm məlumatları yükləyir, həm cavabı pars edir, həm də UI-ni yeniləyir. Refaktorinqdən sonra hər məsuliyyət ayrı komponentə ayrılmışdır.

// SRP pozuntusu: bir sinif hər şeyi edir
class BadUserProfileActivity {
    fun loadUser(userId: Int) {
        // HTTP sorğusu
        // JSON pars etmə
        // UI yeniləmə
        // Verilənlər bazasına yazma
    }
}

// SRP tətbiqindən sonra
class UserRepository {
    fun getUser(userId: Int): User
}

class UserViewModel {
    private val repo: UserRepository
    fun loadUser(userId: Int) { }
}

class UserProfileFragment {
    fun render(user: User) { }
}

iOS Swift-də şəbəkə qatının və təqdimat qatının ayrılması ilə analoji nümunə:

// SRP pozuntusu: ViewController məlumatları və UI-ni idarə edir
class BadProfileViewController: UIViewController {
    func viewDidLoad() {
        // URLSession sorğusu
        // JSON decode
        // Label yeniləmə
    }
}

// SRP tətbiqindən sonra
protocol UserServiceProtocol {
    func fetchUser(id: Int) async throws -> User
}

class ProfileViewModel {
    private let service: UserServiceProtocol
    func loadProfile(id: Int) { }
}

class ProfileViewController: UIViewController {
    func display(user: User) { }
}

SRP refaktorinqi arxitekturanı çətinləşdirmir — məsuliyyəti yenidən bölüşdürür. Kodun miqdarı təkrarların aradan qaldırılması hesabına hətta azala bilər. Hər yeni sinfin dəqiq təyinatı var və müstəqil inkişaf etdirilə bilər.

Kompozisiya irsiliyə alternativ olaraq

Kompozisiya irsiliyin lazımsız bağlılıqlar yaratdığı yerlərdə SRP-yə riayət etməyə kömək edir. Onlarla metodu olan super sinif əvəzinə alt sinif konstruktor vasitəsilə ixtisaslaşmış obyektlər dəsti alır. Hər obyekt öz funksionallığına cavabdehdir.

Android inkişafında Decorator pattern-i orijinal sinfi dəyişmədən məsuliyyətlər əlavə etməyə imkan verir. iOS-da şəbəkə qatında Middleware zənciri loglaşdırma, keşləmə və autentifikasiyanı ayrı modullara bölür.

Tipik SRP pozuntuları və nəticələri

Ən tez-tez rast gəlinən pozuntu — «God Class»: verilənlər bazasını idarə edən, bildirişlər göndərən, hesabatlar hazırlayan və istifadəçi girişini emal edən sinif. Belə sinif layihənin darboğazına çevrilir: hər dəyişiklik tam reqressiv testləşdirmə tələb edir.

Mobil inkişafda SRP pozuntusuna Activity, Fragment və ya ViewController-da biznes məntiqinin və UI məntiqinin qarışdırılması gətirib çıxarır. onClickListener metodu eyni anda məlumatları valide edir, API çağırır və düymələrin görünməsini yeniləyirsə — bu tək məsuliyyət prinsipinin birbaşa pozuntusudur.

SRP pozuntusunun nəticələrinə daxildir: paralel inkişafın çətinliyi (bir faylda konfliktlər), unit-testləşdirmənin çətinləşməsi, dəyişikliklərin yüksək qiyməti və kodun oxunaqlılığının azalması. Sistemli SRP pozuntusu olan layihələr yeni funksionallıq əlavə etmək üçün 2-3 dəfə çox vaxt tələb edir.

Kodda SRP pozuntusunun göstəriciləri

SRP pozuntusunu dolayı əlamətlərlə müəyyən etmək olar: sinif 200 sətirdən çoxdur, tətbiqin müxtəlif qatlarından (UI + network + database) modullar idxal edir, müxtəlif mövzulu 5-dən çox publik metoda malikdir. Bağlılıq metriki (cohesion) — statistik göstərici: sinif daxilində metodların aşağı bağlılığı SRP pozuntusuna işarə edir.

SRP pozuntularını aşkar etmək üçün statik analiz alətlərindən istifadə etmək faydalıdır: Android üçün — Detekt TooManyFunctions qaydası ilə, iOS üçün — SwiftLint file_length qaydası ilə. Bu alətlər ölçü və mürəkkəblik həddini aşan sinifləri işıqlandırır.

SRP-ni pozan siniflərin refaktorinqi Extract Class və ya Extract Delegate vasitəsilə həyata keçirilir: əlaqəli metodlar qrupu ayrı sinfə çıxarılır, orijinal sinif isə onlara çağırışları delegasiya edir. Belə refaktorinqlərin tədricən tətbiqi «God Class»-ı hər biri bir məsuliyyətə malik zəif bağlı modullar dəstinə çevirir. Belə yanaşma inkişafı dayandırmadan arxitekturanı yaxşılaşdırmağa imkan verir — refaktorinq iterativ olaraq, bir moduldan başlayaraq yerinə yetirilir.