Mobil ishlanmada Cohesion (bog‘liqlik): asoslar, darajalar va uni qanday oshirish

Cohesion nima

Cohesion (bog‘liqlik) — bir sinf yoki modul ichidagi metodlar, maydonlar va xususiyatlarning mantiqiy jihatdan qanchalik bog‘liqligini baholaydigan metrikadir. Yuqori bog‘liq modul bitta vazifani bajaradi va faqat uni amalga oshirish uchun zarur elementlarni o‘z ichiga oladi. Past bog‘liq modul bir vaqtning o‘zida bir nechta ishlarni bajarishga harakat qiladi — metodlar mazmunan zaif bog‘langan.

Obyektga yo‘naltirilgan dasturlash kontekstida cohesion Single Responsibility Principle (S) bilan chambarchas bog‘liq. Agar sinf bitta aniq mas’uliyatga ega bo‘lsa, uning cohesion odatda yuqori bo‘ladi. Agar sinf UI, biznes mantiq va tarmoq ishi bilan shug‘ullansa — cohesion past bo‘ladi va bunday sinfni torroq mas’uliyatli bir nechta alohida sinflarga bo‘lish kerak.

Cohesionni tushunish dasturchiga refaktoring qarorlarini qabul qilishda yordam beradi. Sinfda sinf maydonlarini ishlatmaydigan metodni ko‘rsangiz, bu past bog‘liqlik signalidir. Bunday metod yo sinfda ortiqcha, yoki sinf noto‘g‘ri loyihalashtirilgan. Yuqori bog‘liqlikka intilish — bu kodning har bir darajasida arxitekturani yaxshilash bo‘yicha doimiy ishdir.

Bog‘liqlik turlari va darajalari

Dasturiy ta’minot muhandisligida yettita cohesion darajasi mavjud, eng yomondan eng yaxshigacha tartiblangan. Ushbu shkalani tushunish modul sifatini ob’ektiv baholash va refaktoringda qaysi yo‘nalishda harakat qilishni aniqlash imkonini beradi. Daraja qancha yuqori bo‘lsa, kod shuncha xizmat ko‘rsatishga yaroqli va tushunarli bo‘ladi.

Past bog‘liqlik: tasodifiy, mantiqiy va vaqtinchalik

Tasodifiy (coincidental) — eng yomon daraja, elementlar modulda tasodifiy, hech qanday mantiqiy bog‘liqliksiz guruhlangan. Misol: sana formatlash, email jo‘natish va chegirma hisoblash metodlari to‘plangan Utilities sinfi. Bunday sinfni barcha metodlarni o‘qimay turib tushunish mumkin emas va bir metodning o‘zgarishi boshqalarni faqat yonma-yon joylashgani uchun buzishi mumkin.

Mantiqiy (logical) bog‘liqlik — elementlar mantiqiy bog‘langan, ammo mohiyatan farqli vazifalarni bajaradi. parseJSON, parseXML va parseCSV metodlari bo‘lgan sinf „parsing“ mavzusi bilan mantiqiy bog‘langan, ammo har bir metod printsipial jihatdan farqli ish qiladi. Muammo: yangi format (YAML) qo‘shilganda sinf o‘sadi va uning interfeysi shishib ketadi.

Vaqtinchalik (temporal) bog‘liqlik — elementlar bajarilish vaqtiga ko‘ra guruhlangan. Ma’lumotlar bazasini sozlaydigan, konfig yuklaydigan, analitikani ishga tushiradigan AppInitializer sinfi — bularning barchasi ilova ishga tushganda sodir bo‘ladi, ammo vazifalarning o‘zi bog‘liq emas. Ularni har bir mas’uliyat sohasi uchun alohida Initializerlarga bo‘lish yaxshiroq.

O‘rta bog‘liqlik: protsessual va kommunikativ

Protsessual (procedural) bog‘liqlik elementlar bajarilish ketma-ketligi bilan birlashtirilganda yuzaga keladi. „Buyurtmani qayta ishlash” moduli validateCart, processPayment, sendConfirmation metodlarini o‘z ichiga oladi — har bir metod qat’iy oldingisidan keyin chaqiriladi. Bu tasodifiy yoki mantiqiy bog‘liqlikdan yaxshiroq, ammo baribir ideal emas: har bir qadam alohida modulga ajratilishi mumkin.

Kommunikativ (communicational) bog‘liqlik — elementlar bir xil ma’lumotlar bilan ishlaydi. getUser, updateUser, deleteUser metodlari bo‘lgan UserService sinfi umumiy User ob’ekti bilan birlashtirilgan. Bu protsessual bog‘liqlikdan ancha yaxshi: sinf aniq mavzu sohasiga ega. Mobil loyihalardagi Repository sinflarining aksariyati kommunikativ bog‘liqlikka ega.

Yuqori bog‘liqlik: funksional

Funksional (functional) bog‘liqlik — eng yuqori daraja, modulning har bir elementi bitta vazifani bajarishda ishtirok etadi. Uzunlikni, belgilar mavjudligini va parol murakkabligini tekshiradigan yagona validate metodi bo‘lgan PasswordValidator sinfi — funksional bog‘liqlik namunasi. Agar bunday sinf o‘zgarsa, bu faqat parolni tekshirish qoidalari o‘zgargani uchundir.

Funksional bog‘liqlikka erishish — arxitektura refaktoringining asosiy maqsadi. Har bir sinf o‘zgarish uchun aynan bitta sababga ega bo‘lishi kerak. Mobil ishlanmada funksional bog‘liqlik alohida Use Caselar, maxsus Viewlar, formatlagichlar va validatorlarni ajratish orqali erishiladi. Har bir bunday sinf aniq mas’uliyat zonasiga ega to‘liq qurilish blokidir.

Cohesion vs Coupling

Cohesion va coupling — bir sifatning ikki tomoni. Modul ichidagi cohesion qancha yuqori bo‘lsa, modullar orasidagi coupling odatda shuncha past bo‘ladi. Yaxshi loyihalashtirilgan tizim bir vaqtning o‘zida ichki yuqori bog‘liqlikka va tashqi zaif bog‘liqlikka intiladi. Bu qoida 1970-yillardan beri dasturiy ta’minot muhandisligida fundamental hisoblanadi.

Cohesion-coupling nisbatini muvozanat sifatida tasavvur qilish mumkin. Agar dasturchi bir sinfda bir nechta vazifani birlashtirib cohesionni qurbon qilsa, qo‘shni modullar ko‘proq bog‘liqlikka ega bo‘ladi — ular turli maqsadlar uchun bu yuklangan sinfga murojaat qilishga majbur bo‘ladi, bu esa couplingni oshiradi. Va aksincha, kichik yuqori bog‘liq sinflarga bo‘lish modullar orasidagi o‘zaro ta’sir nuqtalarini kamaytiradi.

Amalda bu degani: funksional bog‘liqlikka ega yangi sinfni ajratganingizda, boshqa modullarni uning amalga oshirish tafsilotlarini bilish zaruratidan ozod qilasiz. Masalan, EncryptionManager-ni funksional bog‘liqlikka ega alohida sinfga ajratib, boshqa modullarga shifrlash algoritmining tafsilotlarini tushunish zaruratisiz oddiy encrypt/decrypt interfeysini berasiz.

// Past bog‘liqlik — sinf hamma narsani birdan qiladi
class UserManager {
    fun fetchAndSaveUser(id: String) { }
    fun parseUserJson(json: String): User { }
    fun displayUserName(user: User): String { }
    fun validateEmail(email: String): Boolean { }
}

// Yuqori bog‘liqlik — har bir sinf bitta vazifani hal qiladi
class UserRepository {
    fun fetchUser(id: String): User { }
}

class UserJsonParser {
    fun parse(json: String): User { }
}

class UserNameFormatter {
    fun format(user: User): String { }
}

class EmailValidator {
    fun isValid(email: String): Boolean { }
}

Misol farqni ko‘rsatadi: UserManager mantiqiy bog‘liqlikka ega — barcha metodlar foydalanuvchilar bilan bog‘liq, ammo har biri printsipial jihatdan farqli ish qiladi. Refaktoringdan so‘ng har bir sinf funksional bog‘liqlikka ega bo‘ladi va coupling kamayadi, chunki boshqa modullar faqat o‘zlariga kerakli sinfga bog‘liq bo‘ladi, butun UserManager-ga emas.

Kodda bog‘liqlikni qanday o‘lchash

LCOM (Lack of Cohesion of Methods) — sinf bog‘liqligini o‘lchash uchun eng mashhur metrika. LCOM umumiy maydonlarni ishlatmaydigan metod juftliklari sonini hisoblaydi. 0 qiymati ideal bog‘liqlikni anglatadi (barcha metodlar bir xil maydonlar bilan ishlaydi), yuqori qiymat — past bog‘liqlikni. LCOM4 (takomillashtirilgan versiya) boshqa metodlar orqali tranzitiv bog‘lanishlarni ham hisobga oladi.

Android ishlanmasida bog‘liqlik metrikalarini TooManyFunctions qoidasi bilan Detekt orqali olish mumkin. Turli maydon guruhlaridan foydalanadigan o‘nlab metodlari bo‘lgan sinflar past bog‘liqlikka ega bo‘lishi mumkin. iOSda SwiftLint file_length va function_body_length qoidalariga ega — bilvosita ko‘rsatkichlar: uzun fayllar va metodlar ko‘pincha past cohesionni bildiradi.

Qo‘lda baholash usuli: „Bu sinf bir sababdanmi yoki bir nechta sababdan o‘zgaradimi?” degan savolni bering. Agar bir nechta mustaqil sababni ayta olsangiz — sinf past bog‘liqlikka ega. Ikkinchi test: „Bu sinfni ikkita mustaqil sinfga bo‘lish mumkinmi?” Agar ha — bajaring. Code review vaqtida cohesionni muntazam tekshirish God sinflarining paydo bo‘lishining oldini oladi va texnik qarzni kamaytiradi.

Mobil loyihada Cohesionni qanday oshirish

Birinchi qadam — Single Responsibility Principle-ni qo‘llang. Har bir sinf bitta aniq mas’uliyatga ega bo‘lishi kerak. Agar sinfda uning asosiy vazifasiga tegishli bo‘lmagan metod bo‘lsa, uni alohida sinfga ajrating. IDE-dagi Extract Class yoki Extract Delegate texnikasi bu jarayonni avtomatlashtiradi. Ajratgandan so‘ng asl sinf ko‘proq fokuslangan bo‘lganligini tekshiring.

Ikkinchi qadam — interfeysni soddalashtirish uchun Facade naqshidan foydalaning. Agar sinf 20 metodni taqdim etsa, ulardan mijozlar faqat 3-4 tasini ishlatsa, ehtimol sinf past bog‘liqlikka ega — u juda ko‘p turli funksionallikni taklif qiladi. Metodlarni mavzular bo‘yicha guruhlang va har bir guruh uchun alohida sinflar ajrating, asl sinfni esa fasadga aylantiring yoki o‘chiring.

Uchinchi qadam — maydon guruhlariga e’tibor bering. Agar sinfda metodlarning faqat bir qismi ishlatadigan maydonlar bo‘lsa — bu past cohesion ko‘rsatkichidir. Sinfni maydon guruhlari bo‘yicha bo‘ling. Masalan, sinfda userRepository, networkClient va analyticsTracker maydonlari bo‘lsa, lekin birinchi guruh metodlari faqat userRepository, ikkinchisi esa networkClient ishlatsa — bu ikki turli sinf.

To‘rtinchi qadam — tasodifiy static metodlari bo‘lgan „utility” sinflarini yaratishdan qoching. Utils yoki Helpers sinfidagi har bir static metod ixtisoslashtirilgan sinfga ajratish uchun nomzoddir. FormatUtils.dateToString-ni DateFormatter-ga, ValidationUtils.isValidEmail-ni esa EmailValidator-ga ko‘chirish yaxshiroq. Bu har bir sinfning cohesionini oshiradi va kodni o‘z-o‘zidan hujjatlashtiradigan qiladi.