SRP: bu nima, yagona mas'uliyat tamoyili ishlab chiqishda

SRP (Single Responsibility Principle) nima?

SRP (Single Responsibility Principle) — yagona mas'uliyat tamoyili bo'lib ta'kidlaydi: har bir sinf yoki modul o'zgarish uchun aynan bitta sababga ega bo'lishi kerak. Bu sinf aynan bitta operatsiyani bajarishi kerak degani emas. Gap bir aktyor oldida bitta mas'uliyat bilan birlashtirilgan bog'liq harakatlar guruhi haqida ketmoqda.

Robert Martin SRP ni aktyorlar nuqtayi nazaridan qayta shakllantirdi: sinf faqat bitta manfaatdor shaxs yoki bir guruh odamlarning talabi bilan o'zgarishi kerak. Agar ikki xil aktyor bir sinfning o'zgarishini talab qilsa — mas'uliyat noto'g'ri taqsimlangan.

Masalan, bir vaqtning o'zida maoshni hisoblaydigan (buxgalteriya talabi) va hisobot tayyorlaydigan (rahbariyat talabi) Employee sinfi SRP ni buzadi. Hisoblash qoidalarining o'zgarishi hisobot tayyorlashga ta'sir qilishi mumkin va aksincha.

SRP ning rasmiy ta'rifi

Modul o'zgarish uchun bir va faqat bitta sababga ega bo'lishi kerak. O'zgarish sababi aktyor — talabni ilgari suruvchi shaxs yoki tizim tomonidan belgilanadi. Agar turli aktyorlardan kelgan talablar bir modulning o'zgarishiga olib kelsa — modul SRP ni buzadi.

Aktyor konsepsiyasi SRP ni mavhum tavsiya emas, arxitektura tahlilining amaliy vositasiga aylantiradi. Tizimni loyihalashda savol berish kifoya: “Bu kodni kim o'zgartirishni so'raydi?” — agar javobda bir nechta manfaatdor shaxs bo'lsa, mas'uliyat taqsimlanishi kerak.

Yagona mas'uliyat tamoyili qanday ishlaydi

Yagona mas'uliyat bir sababdan o'zgaradigan metodlarni guruhlash orqali amalga oshiriladi. Sinf bog'liq mantiqning “yig'ilish nuqtasi”ga aylanadi, hamma narsa uchun “Shveytsariya pichog'i” emas. Bu kodni tushunishni soddalashtiradi: dasturchi sinfni ko'radi va uning maqsadini darhol anglaydi.

SRP ning ishlash mexanizmi bitta o'zgarish o'qi qoidasiga asoslanadi. Agar funksionallik mustaqil sabablardan o'zgarishi mumkin bo'lsa — alohida sinflarga ajratilishi kerak. Bu sinflar orasidagi bog'lanishlar kompozitsiya yoki delegatsiya orqali quriladi.

SRP buzilishi turli ma'lumotlar bilan ishlaydigan o'nlab metodlarni o'z ichiga olgan “xudo sinflari”da (God Objects) namoyon bo'ladi. Bunday sinfni testlash qiyin — bir metodning testi qolganlarning hammasi uchun muhitni sozlashni talab qiladi. Bir mas'uliyatning o'zgarishi boshqasini buzishi mumkin, bu kodni mo'rt qiladi.

Amalda SRP dasturchilarga “bu kod qayerda?” degan savolga javob berishga yordam beradi. Agar har bir mas'uliyat o'z sinfiga ajratilgan bo'lsa, kerakli faylni topish soniyalar oladi. MVVM arxitekturasiga ega Android loyihasida bu UserViewModel faqat foydalanuvchi ekrani holati uchun javob beradi, UserRepository esa ma'lumotlarni olish uchun javob beradi degani. Kesh mantiqini qidirayotgan dasturchi ViewModel ga emas, UserCacheRepository ga boradi. Kodning bunday tashkil etilishi yangi jamoa a'zolarining onboardingini tezlashtiradi va refaktoring paytida xatolar sonini kamaytiradi.

Nima uchun SRP mobil ishlab chiqishda muhim

Mobil ishlab chiqish kodning modulliligiga alohida talablar qo'yadi. Android Fragment yoki iOS ViewController ko'pincha mantiqning “tortishish nuqtasi”ga aylanadi: bosishlarni qayta ishlash, API chaqiruvi, javobni pars qilish, UI ni yangilash — hammasi bitta sinfda. SRP bu vazifalarni ajratishni talab qiladi.

Android arxitekturasida SRP Google ning Jetpack bo'yicha tavsiyalariga kiritilgan: ViewModel ekran holati uchun, Repository ma'lumotlar uchun, UseCase biznes mantig'i uchun javob beradi. Har bir komponent o'zgarish uchun bitta sababga ega. iOS ishlab chiqishda MVVM va Coordinator andozalari xuddi shu mantiqqa amal qiladi.

Mobil loyihalarda SRP ga rioya qilish o'lchanadigan afzalliklarni beradi: sinflar hajmining 40-60% ga kamayishi, kod-review vaqtining qisqarishi va yangi funksionallik qo'shilganda regressiv xatolar sonining kamayishi. Izolyatsiya qilingan modullar unit-testlar bilan qoplash va boshqa ekranlarda qayta foydalanish uchun osonroq.

SRP ning testlashga ta'siri

Unit-testlar SRP ga rioya qiladigan sinflar uchun kamroq mock-obyekt va sozlash talab qiladi. Agar sinf bitta mas'uliyatga ega bo'lsa, uning bog'liqliklari cheklangan. Test bitta xatti-harakatni tekshiradi, bir nechta bog'liq bo'lmagan stsenariylarning kombinatsiyasini emas.

Google Testing Blog (2023) hisobotiga ko'ra, yagona mas'uliyatli sinflar agregator sinflar bilan solishtirganda 35% ko'proq test qamrovini ko'rsatadi. Dasturchilar kichik, tushunarli modullar uchun testlarni ko'proq yozadilar.

Android va iOS da SRP misollari

SRP ni buzadigan odatdagi Android sinfini ko'rib chiqaylik — u ma'lumotlarni yuklaydi, javobni pars qiladi va UI ni yangilaydi. Refaktoringdan so'ng har bir mas'uliyat alohida komponentga ajratilgan.

// SRP buzilishi: bitta sinf hamma narsani qiladi
class BadUserProfileActivity {
    fun loadUser(userId: Int) {
        // HTTP so'rovi
        // JSON pars qilish
        // UI yangilash
        // Ma'lumotlar bazasiga saqlash
    }
}

// SRP qo'llanilgandan keyin
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 da tarmoq qatlami va taqdimot qatlamini ajratish bilan o'xshash misol:

// SRP buzilishi: ViewController ma'lumotlar va UI ni boshqaradi
class BadProfileViewController: UIViewController {
    func viewDidLoad() {
        // URLSession so'rovi
        // JSON dekodlash
        // Label yangilash
    }
}

// SRP qo'llanilgandan keyin
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 refaktoringi arxitekturni murakkablashtirmaydi — mas'uliyatni qayta taqsimlaydi. Kod miqdori takrorlanishlarni bartaraf etish hisobiga hatto kamayishi mumkin. Har bir yangi sinf aniq maqsadga ega va mustaqil rivojlanishi mumkin.

Kompozitsiya merosga alternativa sifatida

Kompozitsiya meros keraksiz bog'liqliklarni yaratadigan joylarda SRP ga rioya qilishga yordam beradi. O'nlab metodli super sinf o'rniga, pastki sinf konstruktor orqali ixtisoslashgan obyektlar to'plamini oladi. Har bir obyekt o'z funksionalligi uchun javob beradi.

Android ishlab chiqishda Decorator andozasi asl sinfni o'zgartirmasdan mas'uliyatlar qo'shish imkonini beradi. iOS da tarmoq qatlamidagi Middleware zanjiri loglash, keshlash va autentifikatsiyani alohida modullarga ajratadi.

SRP ning tipik buzilishlari va oqibatlari

Eng ko'p uchraydigan buzilish — “God Class”: ma'lumotlar bazasini boshqaradigan, bildirishnomalar yuboradigan, hisobotlar tayyorlaydigan va foydalanuvchi kiritishini qayta ishlaydigan sinf. Bunday sinf loyihaning tor bo'yniga aylanadi: har qanday o'zgarish to'liq regressiv testlashni talab qiladi.

Mobil ishlab chiqishda SRP buzilishiga Activity, Fragment yoki ViewController da biznes mantig'i va UI mantig'ini aralashtirish olib keladi. onClickListener metodi bir vaqtning o'zida ma'lumotlarni validatsiya qilsa, API chaqirsa va tugmalarning ko'rinishini yangilasa — bu yagona mas'uliyat tamoyilining bevosita buzilishidir.

SRP buzilishining oqibatlariga kiradi: parallel ishlab chiqish qiyinligi (bir faylda konfliktlar), unit-testlashning qiyinlashishi, o'zgarishlarning yuqori narxi va kodning o'qiluvchanligining pasayishi. Tizimli SRP buzilishi bo'lgan loyihalar yangi funksionallik qo'shish uchun 2-3 baravar ko'p vaqt talab qiladi.

Kodda SRP buzilishining ko'rsatkichlari

SRP buzilishini bilvosita belgilar bilan aniqlash mumkin: sinf 200 qatordan ortiq, dasturning turli qatlamlaridan (UI + network + database) modullarni import qiladi, turli mavzudagi 5 dan ortiq umumiy metodga ega. Bog'liqlik metriksi (cohesion) — statistik ko'rsatkich: sinf ichidagi metodlarning past bog'liqligi SRP buzilishiga ishora qiladi.

SRP buzilishlarini aniqlash uchun statik tahlil vositalaridan foydalanish foydali: Android uchun — Detekt TooManyFunctions qoidasi bilan, iOS uchun — SwiftLint file_length qoidasi bilan. Bu vositalar o'lcham va murakkablik chegarasidan oshgan sinflarni belgilaydi.

SRP ni buzadigan sinflarning refaktoringi Extract Class yoki Extract Delegate orqali amalga oshiriladi: bog'liq metodlar guruhi alohida sinfga ajratiladi va asl sinf ularga chaqiruvlarni delegatsiya qiladi. Bunday refaktoringlarning bosqichma-bosqich qo'llanilishi “God Class” ni har biri bitta mas'uliyatga ega zaif bog'langan modullar to'plamiga aylantiradi. Bunday yondashuv ishlab chiqishni to'xtatmasdan arxitekturni yaxshilash imkonini beradi — refaktoring iterativ ravishda, bir vaqtning o'zida bitta modul bilan amalga oshiriladi.