DRY mobil ishlanmada — bu nima, prinsip va nima uchun takrorlanish zararli

DRY nima?

DRY (Don't Repeat Yourself) — loyihada har bir bilim elementining bir marta saqlanishini talab qiladigan ishlanma prinsipi. Bu degani, har qanday mantiq, konfiguratsiya yoki metama‘lumotlar aynan bir joyda mavjud bo‘lishi kerak.

Termin Endi Xant va Deyv Tomas tomonidan 1999 yilda “The Pragmatic Programmer” kitobida kiritilgan. Mualliflar DRY ni “har bir bilim qismi tizimda yagona, izchil ifodaga ega bo‘lishi kerak” deb ta‘riflagan. DRY ning aksi — takrorlanish norma hisoblanadigan WET (Write Everything Twice) yondashuvi.

University of California, Davis (2019) tadqiqotiga ko‘ra, yuqori darajadagi kod takrorlanishiga ega loyihalar xatolarni tuzatishga 42% ko‘proq vaqt sarflaydi. Sababi shundaki, dasturchi bir fragmentning barcha nusxalarini topib o‘zgartirishi kerak — qo‘lda qidirishda o‘tkazib yuborishlar muqarrar.

DRY ni kod sifati mezoni sifatida qo‘llang. Agar bir xil naqsh loyihada uch marta uchrayotganini sezsangiz — to‘rtinchi takrorlanishni kutmasdan uni abstraksiyaga ajrating.

DRY ni yagona javobgarlik prinsipidan farqi

Single Responsibility Principle (SRP) SOLID dan sinfning o‘zgarish uchun bitta sababi bo‘lishi kerakligini ta‘kidlaydi. DRY kengroq: u nafaqat sinflarni, balki ma‘lumotlar, konfiguratsiya, hujjatlarni va hatto biznes qoidalarini ham qamrab oladi. SRP javobgarlik chegaralari haqida, DRY — nusxa ko‘chirishning yo‘l qo‘yilmasligi haqida.

Mobil ishlanmada bu farq ayniqsa sezilarli. Agar bir xil biznes qoidasi (soliq hisoblash, sana formatlash) Android va iOS qismlarida takrorlansa — bu DRY ning buzilishi, garchi SRP har bir platforma ichida rasmiy ravishda bajarilgan bo‘lsa ham. Yechim — umumiy mantiqni shared-modulga (KMM, C++) ajratish.

Google Android Architecture Guidelines (2023) hisobotiga ko‘ra, biznes mantiq uchun umumiy modullardan foydalanadigan jamoalar talablar o‘zgarganda xatolar sonini platformalar bo‘ylab takrorlanuvchi mantiqli loyihalarga nisbatan 37% ga kamaytiradi.

Nima uchun kod takrorlanishi xavfli?

Takrorlanish — mobil loyihalarda texnik qarzning asosiy manbai. Har bir kod nusxasi yashirin bog‘liqlik yaratadi: xatti-harakatni o‘zgartirish uchun barcha nusxalarni topish va yangilash kerak. Hech bo‘lmaganda bittasini o‘tkazib yuborish xato degani.

Klassik vaziyatni ko‘rib chiqaylik: Android ilovasida sana formatlash uch xil Activity da amalga oshiriladi. Yangi formatga (masalan, ISO 8601) o‘tishda dasturchi ikkita faylni tuzatadi, uchinchisini unutadi — va foydalanuvchi sanani eski formatda ko‘radi. Ilova reytingi tushadi va xatoni qidirish ikki barobar ko‘proq vaqt oladi.

Google Research (2020) tadqiqoti ko‘rsatdi: mobil ilovalardagi kritik xatolarning 68% takrorlanuvchi kodning sinxron bo‘lmagan o‘zgartirilishi bilan bog‘liq. Bunday xatoni production da tuzatish narxi kod boshidan yagona bo‘lganidan 4,5 barobar yuqori.

Copy-paste aniqlanishini taqiqlovchi qoidalar bilan statik analizatordan (Detekt, SwiftLint) foydalaning. CI ni N qatordan ortiq takrorlanishga ega pull-requestlar asoslanmasdan review dan o‘tmasligi uchun sozlang.

DRY mobil ishlanmada: amaliy misollar

Android da UI mantiqining takrorlanishi

Oddiy anti-naqsh — RecyclerView adapterini kichik o‘zgarishlar bilan nusxalash. Konfiguratsiyali universal adapter o‘rniga dasturchilar har bir ekran uchun alohida sinf yaratadilar. Umumiy bazaviy sinfni ajratish bilan refaktoring kodni 30–50% qisqartiradi.

// Takrorlanish: ikkita alohida adapter
class UserAdapter {
    fun bind(item: User) { /* ... */ }
}
class ProductAdapter {
    fun bind(item: Product) { /* ... */ }
}

// DRY-refaktoring: umumiy bazaviy sinf
abstract class BaseAdapter<T> {
    abstract fun bind(item: T)
}
class UserAdapter : BaseAdapter<User>() { /* ... */ }
class ProductAdapter : BaseAdapter<Product>() { /* ... */ }

Birinchi misolda har bir adapter bind mexanizmini qaytadan amalga oshiradi. Yangi mantiq (analitika, loglash) qo‘shilganda har bir faylni o‘zgartirish kerak bo‘ladi. Bazaviy sinf bu takrorlanishni bartaraf qiladi: umumiy mantiq bir joyda, xususiy mantiq vorislarda yashaydi.

iOS da tarmoq so‘rovlarining takrorlanishi

iOS loyihalarida URLSession konfiguratsiyasi — sarlavhalar, kutish vaqtlari, xato boshqaruvi tez-tez takrorlanadi. Har bir xizmat takrorlanuvchi sozlamalar bilan o‘z seansini yaratadi.

// Takrorlanish: har bir xizmat seansni qaytadan sozlaydi
class UserService {
    let session = URLSession(configuration: {
        let cfg = URLSessionConfiguration.default
        cfg.timeoutIntervalForRequest = 30
        cfg.httpAdditionalHeaders = ["Authorization": "Bearer ..."]
        return cfg
    }())
}

// DRY: yagona seans fabrikasi
struct NetworkConfig {
    static var session: URLSession {
        let cfg = URLSessionConfiguration.default
        cfg.timeoutIntervalForRequest = 30
        cfg.httpAdditionalHeaders = ["Authorization": "Bearer ..."]
        return URLSession(configuration: cfg)
    }
}

Konfiguratsiyani yagona NetworkConfig ga ajratish barcha xizmatlarning bir xil sarlavhalar va kutish vaqtlaridan foydalanishini kafolatlaydi. Bir joydagi o‘zgarish avtomatik ravishda barcha so‘rovlarga qo‘llaniladi — bu API kaliti yoki protokol versiyasi o‘zgarganda xato xavfini kamaytiradi.

Android va iOS da DRY qanday qo‘llaniladi?

Meros va kompozitsiya orqali DRY

Meros — takrorlanishni bartaraf qilishning tabiiy usuli: umumiy mantiq bazaviy sinfga, xususiy mantiq vorislarga ajratiladi. Biroq mobil ishlanmada merosdan suiiste‘mol qilish qiyin saqlanadigan qattiq iyerarxiyalarni keltirib chiqaradi. Kompozitsiya (bog‘liqlik inyeksiyasi) — yanada moslashuvchan alternativ.

Google I/O 2023: Modern Android Architecture tahlili shuni ko‘rsatdiki, Google jamoalarining 76% takrorlanishni bartaraf qilish uchun meros o‘rniga kompozitsiyani afzal ko‘radi. O‘n metodli BaseViewModel o‘rniga har bir biznes operatsiyasi uchun alohida UseCase sinflarini ajratish va ularni kerakli joyga inyeksiya qilish tavsiya etiladi.

“is-a” munosabatlaridan tashqari barcha holatlarda kompozitsiyani tanlang. Agar A sinfi B sinfining ixtisoslashuvi bo‘lsa — meros mos keladi. Agar A oddiygina B ning funksionalligidan foydalansa — kompozitsiyadan foydalaning.

Yordamchi sinflar orqali DRY

Yordamchi sinflar (Extensions, Helpers) — takrorlanishdan qochishning eng oddiy usuli. Oddiy nomzodlar: sana formatlash, email validatsiyasi, birlik konvertatsiyasi, SharedPreferences/UserDefaults bilan ishlash.

// DRY: yagona sana formatlash funksiyasi
fun Date.toDisplayFormat(): String {
    val sdf = SimpleDateFormat("dd.MM.yyyy", Locale.getDefault())
    return sdf.format(this)
}

// Ilovaning istalgan joyida foydalanish
textView.text = Date().toDisplayFormat()

Date.toDisplayFormat() kengaytmasi bir marta e‘lon qilinadi va butun loyihada mavjud bo‘ladi. Formatni “dd.MM.yyyy” dan “yyyy-MM-dd” ga o‘zgartirish kerak bo‘lsa — tuzatish bir faylda, formatlash uchraydigan har bir Activity yoki Fragment da emas. Bu aynan DRY ning mohiyatidir.

Gradle konfiguratsiyasida DRY (Android)

Ko‘p modulli Android loyihalari ko‘pincha har bir build.gradle da bog‘liqlik versiyalarini takrorlaydi. Yechim — barcha versiyalarni bir faylda markazlashtiradigan version catalog (libs.versions.toml).

Android Developer Documentation (2024) ga ko‘ra, version catalog ga migratsiya bog‘liqlik konfliktlarini 52% ga kamaytiradi va yagona tuzatish nuqtasi hisobiga qurilishni tezlashtiradi.

Version catalog ni loyihaning boshida yoki modullarning birinchi reorganizatsiyasida joriy qiling. Agar loyihada allaqachon takrorlanish mavjud bo‘lsa — migratsiya uchun bir kun ajrating: bu kutubxonalarning navbatdagi yangilanishida o‘zini oqlaydi.

DRY ga amal qilishdagi odatiy xatolar

Muddatidan oldin abstraksiya

Muddatidan oldin abstraksiya — yangi boshlovchilarning eng keng tarqalgan xatosi. Dasturchi ikkita o‘xshash kod qatorini ko‘radi va ularni darhol umumiy funksiyaga ajratadi. Bir oydan keyin talablar o‘zgaradi va umumiy funksiya parametrlar va bayroqlar bilan to‘lib ketadi — dastlabki takrorlanishdan murakkabroq bo‘ladi. Rule of Three aynan shundan himoya qiladi: bir-ikki marta uchragan narsani abstraksiya qilmang.

Martin Fauler Refactoring (2019) kitobida tavsiya qiladi: “Kodning takrorlanishi har doim yomon emas. Bilimning takrorlanishi yomon”. Agar ikki qator tasodifan mos kelsa, lekin turli tushunchalarni ifodalasa — bu takrorlanish emas, balki tasodif. Rule of Three tasodifiy moslikni tizimli takrorlanishdan farqlashga yordam beradi.

Abstraksiya qilishdan oldin semantikani baholang. Bir xil ma‘noli nusxalangan kod — DRY ning buzilishi. Turli ma‘noli, ammo o‘xshash sintaksisli kod — abstraksiyani talab qilmaydigan tasodif.

Haddan tashqari parametrlash

Haddan tashqari parametrlash bir funksiya barcha mumkin bo‘lgan stsenariylarni bayroqlar va boolean parametrlar orqali qamrab olishga harakat qilganda yuzaga keladi. Bunday kod SRP ni buzadi va o‘qib bo‘lmaydigan bo‘ladi. Alomat: agar funksiyada ikkitadan ortiq boolean parametr bo‘lsa — bu haddan tashqari abstraksiyaning kodi hidi (code smell).

useCache: Boolean bayroqli bitta funksiya o‘rniga ikkita alohida funksiya yaratish yaxshiroq: fetchFromNetwork() va fetchFromCache(). Aniqlik quruq abstraksiyadan muhimroq — bu KISS prinsipi bilan mos keladi.

Funksiya 3+ boolean parametrga yetganda haddan tashqari parametrlashni refaktor qiling. Aniq nomlar bilan alohida funksiyalarga bo‘ling — har bir chaqiruv o‘z-o‘zini hujjatlashtiradigan bo‘ladi.