Mobil rivojlanishda arxitektura prinsiplari: ular nima, qanday turlari bor va qanday qo'llaniladi

SOLID prinsiplari

Arxitektura prinsiplari — sifatli kodning asosidir. SOLID Robert Martin («Bob Amaki») tomonidan kiritilgan, ob'ektga yo'naltirilgan dizaynning besh prinsipini tavsiflovchi qisqartmadir. SOLIDga amal qilish kodni yanada moslashuvchan, sinab ko'riladigan va o'zgarishlarga chidamli qiladi. Arxitektura prinsiplarini buzish texnik qarzning asosiy sabablaridan biridir.

Keling, har bir prinsipni ko'rib chiqaylik. Single Responsibility Principle (SRP) — har bir sinf o'zgartirish uchun faqat bitta sababga ega bo'lishi kerak. Open/Closed Principle (OCP) — sinflar kengaytirish uchun ochiq, lekin o'zgartirish uchun yopiq. Liskov Substitution Principle (LSP) — pastki turlarning ob'ektlari mantiqni buzmasdan asosiy turdagi ob'ektlarni almashtira olishi kerak. Interface Segregation Principle (ISP) — bitta umumiy interfeysdan ko'ra ko'plab ixtisoslashgan interfeyslar yaxshiroq. Dependency Inversion Principle (DIP) — aniq tatbiqlarga emas, abstraksiyalarga bog'liq bo'ling.

SonarQube tahliliga (2025) ko'ra, SOLID prinsiplarining buzilishi tijorat loyihalarining 68 foizida uchraydi. Eng keng tarqalgan muammolar SRP buzilishi (35%) va ISP buzilishidir (22%). IT Sectr da biz SOLIDni arxitektura ko'rib chiqish bosqichida qo'llaymiz — bu muammolarni texnik qarzga aylanishidan oldin aniqlashga yordam beradi.

Single Responsibility Principle (SRP)

SRP (Yagona Mas'uliyat Prinsipi) — eng muhim va shu bilan birga eng ko'p buziladigan SOLID prinsipi. U shunday deydi: sinf o'zgartirish uchun faqat bitta sababga ega bo'lishi kerak. Agar sinf juda ko'p ish qilsa, uni sinash, o'zgartirish va tushunish qiyin.

Odatiy buzilish — bir vaqtning o'zida ma'lumotlarni qayta ishlaydigan, ma'lumotlar bazasida saqlaydigan va elektron pochta xabarlarini yuboradigan sinf. Quyidagi misol Kotlin da SRP buzilishini va uni qanday tuzatishni ko'rsatadi.

// SRP buzilishi — sinf uch xil ish qiladi
class UserService {
    fun registerUser(email: String, name: String) {
        // 1. Ma'lumotlarni tekshirish
        if (!email.contains("@")) throw IllegalArgumentException("Invalid email")
        
        // 2. Ma'lumotlar bazasida saqlash
        val user = User(email, name)
        database.save(user)
        
        // 3. Xabar yuborish
        emailService.sendWelcomeEmail(email, name)
    }
}

// Tuzatish — uch sinfga bo'lish
class UserRegistrationService {
    fun register(email: String, name: String) {
        UserValidator().validate(email)
        val user = User(email, name)
        UserRepository().save(user)
        NotificationService().sendWelcome(user)
    }
}

Tuzatilgan versiyada har bir sinf o'z vazifasi uchun mas'ul: UserValidator — tekshirish uchun, UserRepository — saqlash uchun, NotificationService — xabarlar uchun. Bu kodni sinab ko'riladigan va qayta ishlatiladigan qiladi — tekshirish mantiqini o'zgartirmasdan ma'lumotlar bazasi tatbiqini almashtirishingiz mumkin.

GRASP va Law of Demeter

GRASP (General Responsibility Assignment Software Patterns) — Craig Larman tomonidan tasvirlangan, ob'ektlar o'rtasida mas'uliyat taqsimlashning to'qqiz arxitektura prinsipi. SOLID dan farqli o'laroq, GRASP «qaysi sinf ushbu metodni o'z ichiga olishi kerak?» degan savolga javob beradi. Asosiy naqshlar: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations.

Law of Demeter (LoD, minimal bog'liqlik prinsipi) — oddiy qoida: ob'ekt faqat bevosita qo'shnilari bilan muloqot qilishi kerak. a.getB().getC().doSomething() yozilmasligi kerak — bu sinflar o'rtasida kuchli bog'liqlik yaratadi. LoD qayta foydalanish imkoniyatini yaxshilaydi va sinashni soddalashtiradi.

IT Sectr da biz Kod Ko'rib Chiqish paytida LoD ga rioya qilishni tekshiramiz. Agar metod uch yoki undan ortiq ob'ektdan «o'tsa», bu arxitekturani soddalashtirish kerakligiga ishora. LoD buzilishi katta loyihalarda eng keng tarqalgan Code Smell lardan biridir.

DRY / KISS / YAGNI

DRY (Don't Repeat Yourself), KISS (Keep It Simple, Stupid) va YAGNI (You Ain't Gonna Need It) — har bir ishlab chiqaruvchiga ma'lum bo'lgan uchta asosiy arxitektura prinsipi. Soddaligiga qaramay, buzilishlar doimiy ravishda sodir bo'ladi.

DRY — kodni takrorlamang. Agar bir xil mantiq ikki joyda paydo bo'lsa, uni umumiy metod yoki sinfga chiqaring. Takrorlash xatolarning asosiy manbai: bir joydagi tuzatish boshqa joyda qo'llash unutiladi. DRY o'xshash kod bo'lishi mumkin emas degani emas — muhimi biznes mantiqining takrorlanmasligidir.

KISS — qanchalik sodda, shunchalik yaxshi. Ko'plab abstraksiyalar va meroslarga ega murakkab yechimlar ko'pincha haddan tashqari. Oddiy yechim bilan boshlang va faqat kerak bo'lganda murakkablashtiring. YAGNI — «bir kundan keyin» kerak bo'lishi mumkin bo'lgan funksionallik uchun kod yozmang. Bu kod bazasining shishishiga va texnik xizmat ko'rsatish murakkabligining oshishiga olib keladi.

DRY — Don't Repeat Yourself

DRY — bu shunchaki nusxa ko'chirishning yo'qligi emas. Bu bilim yoki mantiqning har bir qismi tizimda yagona, aniq ifodaga ega bo'lishi kerak bo'lgan prinsipdir. Takrorlash aniq (ko'chirilgan kod) va yashirin (turli qatlamlarda bir xil mantiq) bo'lishi mumkin.

IT Sectr da biz takrorlashni aniqlash uchun kod tahlili metrikalaridan foydalanamiz. SonarQube va Detekt kabi vositalar takrorlangan kodning foizini ko'rsatadi. 5% dan yuqori qiymat refaktoring uchun sababdir. Biroq, esda tutish muhim: DRY noto'g'ri abstraksiyalar evaziga erishilmasligi kerak — ba'zida ikkita o'xshash kod qismini birlashtirish tushunishni murakkablashtirsa, ularni o'z holicha qoldirish yaxshiroqdir.

Separation of Concerns va Modullilik

Separation of Concerns (SoC) — tizim mustaqil qismlarga (concerns) bo'linadigan, har biri o'z vazifasini hal qiladigan arxitektura prinsipi. Klassik misol — qatlamlarga bo'lish: taqdimot, biznes mantiq, ma'lumotlarga kirish. Har bir qatlam faqat pastdagi qatlamga bog'liq.

Modullilik — tizimni modullarga bo'lish mumkin bo'lgan daraja. Modul — aniq belgilangan interfeysga ega mantiqiy bog'liq sinflar guruhi. Modullar zaif bog'langan (low coupling) va kuchli uyg'un (high cohesion) bo'lishi kerak.

Cohesion vs Coupling

Cohesion (uyg'unlik) — bir modul ichidagi elementlarning bir-biri bilan qanchalik bog'liqligini o'lchovidir. Yuqori uyg'unlik yaxshi: sinf bitta narsani qiladi va uni yaxshi qiladi. Past coupling (bog'liqlik) — modullarning bir-biridan qanchalik mustaqilligini o'lchovidir. Past bog'liqlik yaxshi: bir moduldagi o'zgarish boshqalarni buzmaydi.

Ideal arxitektura yuqori uyg'unlik va past bog'liqlikdir. Amalda bu shuni anglatadi: sinf bir xil ma'lumotlar ustida ishlaydigan metodlarni o'z ichiga oladi (uyg'unlik) va faqat abstraksiyalarga bog'liq, aniq tatbiqlarga emas (bog'liqlik). Muvozanatning buzilishi «Xudo Ob'ektlari» yoki «spagetti kod» ga olib keladi.

Texnik qarz va Code Smell

Texnik qarz (Technical Debt) — Ward Cunningham tomonidan kiritilgan, jamoa optimal bo'lmagan arxitektura qarorlari va arxitektura prinsiplarini buzish uchun to'laydigan «foiz» ni tavsiflovchi metafora. Moliyaviy qarz kabi, texnik qarz ham qasddan (tez qilishga qaror qildik, keyin qayta qilamiz) va qasddan bo'lmagan (tajriba etishmasligi sababli yomon arxitektura) bo'lishi mumkin.

Code Smell — koddagi chuqur muammolarning yuzaki belgilari. Bu atama Martin Fowler tomonidan «Refactoring» kitobida ommalashtirilgan. Oddiy Code Smell lar: uzun metodlar, katta sinflar, uzun chaqiruv zanjirlari, kod takrorlanishi, sharhlarning haddan tashqari ko'p ishlatilishi (aniq kod o'rniga).

IT Sectr da texnik qarz Jira da alohida vazifalar sifatida kuzatiladi. Har bir sprintda biz refaktoring va qarzni to'lash uchun vaqtning 20 foizini ajratamiz. Texnik qarz bilan tizimli ishlash yangi xususiyat qo'shish noldan ishlab chiqishdan ko'proq vaqt talab qiladigan vaziyatni oldini olishning yagona usulidir.