Mobil inkişafda memarlıq prinsipləri: bunlar nədir, hansı növləri var və necə tətbiq edilir

SOLID prinsipləri

Memarlıq prinsipləri — keyfiyyətli kodun təməlidir. SOLID Robert Martin («Bob Əmi») tərəfindən təqdim edilən, obyekt yönümlü dizaynın beş prinsipini təsvir edən bir akronimdir. SOLID-ə əməl etmək kodu daha çevik, test edilə bilən və dəyişikliklərə davamlı edir. Memarlıq prinsiplərinin pozulması texniki borcun əsas səbəblərindən biridir.

Hər prinsipi nəzərdən keçirək. Single Responsibility Principle (SRP) — hər sinfin dəyişiklik üçün yalnız bir səbəbi olmalıdır. Open/Closed Principle (OCP) — siniflər genişləndirmə üçün açıq, lakin dəyişiklik üçün qapalıdır. Liskov Substitution Principle (LSP) — alt tiplərin obyektləri məntiqi pozmadan əsas tipin obyektlərini əvəz edə bilməlidir. Interface Segregation Principle (ISP) — bir ümumi interfeysdən çoxlu ixtisaslaşmış interfeys daha yaxşıdır. Dependency Inversion Principle (DIP) — konkret tətbiqlərdən deyil, abstraksiyalardan asılı olun.

SonarQube analizinə (2025) görə, SOLID prinsiplərinin pozulması kommersiya layihələrinin 68%-də baş verir. Ən çox yayılmış problemlər SRP pozulması (35%) və ISP pozulmasıdır (22%). IT Sectr-da SOLID-i memarlıq baxışı mərhələsində tətbiq edirik — bu, problemlərin texniki borca çevrilməzdən əvvəl aşkarlanmasına kömək edir.

Single Responsibility Principle (SRP)

SRP (Tək Məsuliyyət Prinsipi) — ən vacib və eyni zamanda ən çox pozulan SOLID prinsipidir. Bu deyir: bir sinfin dəyişiklik üçün yalnız bir səbəbi olmalıdır. Bir sinif çox iş görürsə, onu test etmək, dəyişdirmək və anlamaq çətindir.

Tipik bir pozuntu eyni anda məlumatları emal edən, verilənlər bazasında saxlayan və e-poçt bildirişləri göndərən bir sinifdir. Aşağıdakı nümunə Kotlin-də SRP pozulmasını və onu necə düzəltməyi göstərir.

// SRP pozulması — sinif üç fərqli iş görür
class UserService {
    fun registerUser(email: String, name: String) {
        // 1. Məlumat doğrulaması
        if (!email.contains("@")) throw IllegalArgumentException("Invalid email")
        
        // 2. Verilənlər bazasında saxla
        val user = User(email, name)
        database.save(user)
        
        // 3. Bildiriş göndər
        emailService.sendWelcomeEmail(email, name)
    }
}

// Düzəliş — üç sinfə bölmə
class UserRegistrationService {
    fun register(email: String, name: String) {
        UserValidator().validate(email)
        val user = User(email, name)
        UserRepository().save(user)
        NotificationService().sendWelcome(user)
    }
}

Düzəldilmiş versiyada hər sinif öz vəzifəsi üçün məsuliyyət daşıyır: UserValidator — doğrulama üçün, UserRepository — saxlama üçün, NotificationService — bildirişlər üçün. Bu, kodu test edilə bilən və təkrar istifadə oluna bilən edir — doğrulama məntiqini dəyişmədən verilənlər bazası tətbiqini əvəz edə bilərsiniz.

GRASP və Law of Demeter

GRASP (General Responsibility Assignment Software Patterns) — Craig Larman tərəfindən təsvir edilən, obyektlər arasında məsuliyyət bölgüsü üçün doqquz memarlıq prinsipi. SOLID-dən fərqli olaraq, GRASP «hansı sinif bu metodu ehtiva etməlidir?» sualına cavab verir. Əsas nümunələr: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations.

Law of Demeter (LoD, minimal bağlantı prinsipi) — sadə bir qayda: bir obyekt yalnız birbaşa qonşuları ilə əlaqə qurmalıdır. a.getB().getC().doSomething() yazılmamalıdır — bu siniflər arasında güclü bağlantı yaradır. LoD təkrar istifadə qabiliyyətini yaxşılaşdırır və testi sadələşdirir.

IT Sectr-da Kod İcmalı zamanı LoD-ə uyğunluğu yoxlayırıq. Bir metod üç və ya daha çox obyektdən «keçirsə», bu memarlığın sadələşdirilməsinə ehtiyac olduğuna işarədir. LoD pozulması böyük layihələrdə ən çox yayılmış Code Smell-lərdən biridir.

DRY / KISS / YAGNI

DRY (Don't Repeat Yourself), KISS (Keep It Simple, Stupid) və YAGNI (You Ain't Gonna Need It) — hər tərtibatçıya məlum olan üç əsas memarlıq prinsipi. Sadəliyinə baxmayaraq, pozuntular daim baş verir.

DRY — kodu təkrarlamayın. Eyni məntiq iki yerdə görünürsə, onu ümumi bir metod və ya sinfə çıxarın. Təkrarlama səhvlərin əsas mənbəyidir: bir yerdəki düzəliş başqa yerdə tətbiq edilməyi unudulur. DRY oxşar kodun ola bilməyəcəyi anlamına gəlmir — vacib olan biznes məntiqinin təkrarlanmamasıdır.

KISS — nə qədər sadə, o qədər yaxşı. Çoxlu abstraksiya və miras olan mürəkkəb həllər çox vaxt həddindən artıqdır. Sadə bir həll ilə başlayın və yalnız lazım olduqda mürəkkəbləşdirin. YAGNI — «bir gün sonra» lazım ola biləcək funksionallıq üçün kod yazmayın. Bu, kod bazasının şişməsinə və texniki xidmət mürəkkəbliyinin artmasına səbəb olur.

DRY — Don't Repeat Yourself

DRY — bu sadəcə kopyalama-yapışdırmanın olmaması deyil. Bu, bilik və ya məntiqin hər hissəsinin sistemdə tək, birmənalı təmsilə malik olması prinsipidir. Təkrarlama aşkar (kopyalanmış kod) və gizli (müxtəlif təbəqələrdə eyni məntiq) ola bilər.

IT Sectr-da təkrarlamanı aşkar etmək üçün kod analizi metrikalarından istifadə edirik. SonarQube və Detekt kimi alətlər təkrarlanan kodun faizini göstərir. 5%-dən yuxarı dəyər refaktoring üçün səbəbdir. Bununla belə, xatırlamaq vacibdir: DRY səhv abstraksiyalar hesabına əldə edilməməlidir — bəzən iki oxşar kod parçasını birləşdirmək anlamanı çətinləşdirəcəksə, olduğu kimi buraxmaq daha yaxşıdır.

Separation of Concerns və Modulluq

Separation of Concerns (SoC) — sistemin müstəqil hissələrə (concerns) bölündüyü, hər birinin öz vəzifəsini həll etdiyi bir memarlıq prinsipidir. Klassik nümunə təbəqələrə bölməkdir: təqdimat, biznes məntiqi, məlumat girişi. Hər təbəqə yalnız aşağıdakı təbəqədən asılıdır.

Modulluq — sistemin modullara bölünə bilmə dərəcəsidir. Modul yaxşı müəyyən edilmiş interfeysi olan məntiqi əlaqəli siniflər qrupudur. Modullar zəif bağlı (low coupling) və güclü uyğun (high cohesion) olmalıdır.

Cohesion vs Coupling

Cohesion (uyğunluq) — eyni modul daxilində elementlərin bir-biri ilə nə dərəcədə əlaqəli olduğunun ölçüsüdür. Yüksək uyğunluq yaxşıdır: bir sinif bir şey edir və onu yaxşı edir. Aşağı coupling (bağlılıq) — modulların bir-birindən nə dərəcədə müstəqil olduğunun ölçüsüdür. Aşağı bağlılıq yaxşıdır: bir moduldakı dəyişiklik digərlərini pozmur.

İdeal memarlıq yüksək uyğunluq və aşağı bağlılıqdır. Praktikada bu o deməkdir: bir sinif eyni məlumatlar üzərində işləyən metodları ehtiva edir (uyğunluq) və yalnız abstraksiyalardan asılıdır, konkret tətbiqlərdən deyil (bağlılıq). Balanssızlıq «Tanrı Obyektləri» və ya «spagetti kod»a gətirib çıxarır.

Texniki borc və Code Smell

Texniki borc (Technical Debt) — Ward Cunningham tərəfindən təqdim edilən, bir komandanın optimal olmayan memarlıq qərarları və memarlıq prinsiplərinin pozulması üçün ödədiyi «faizi» təsvir edən bir metafora. Maliyyə borcu kimi, texniki borc da qəsdən (tez etmək qərarına gəldik, sonra yenidən edəcəyik) və qəsdən olmayan (təcrübə çatışmazlığı səbəbindən pis memarlıq) ola bilər.

Code Smell — koddakı dərin problemlərin səthi əlamətləridir. Termin Martin Fowler tərəfindən «Refactoring» kitabında populyarlaşdırılıb. Tipik Code Smell-lər: uzun metodlar, böyük siniflər, uzun çağırış zəncirləri, kod təkrarlanması, şərhlərin həddindən artıq istifadəsi (aydın kod əvəzinə).

IT Sectr-da texniki borc Jira-da ayrıca tapşırıqlar kimi izlənilir. Hər sprintdə refaktoring və borcun ödənilməsi üçün vaxtın 20%-ni ayırırıq. Texniki borcla sistematik işləmək, yeni bir xüsusiyyət əlavə etməyin sıfırdan inkişaf etdirməkdən daha çox vaxt apardığı bir vəziyyətdən qaçmağın yeganə yoludur.