DRY mobil inkişafda — bu nədir, prinsipi və təkrarlanma niyə zərərlidir

DRY nədir?

DRY (Don't Repeat Yourself) — layihədə hər bir bilik elementinin tək dəfə saxlanmasını tələb edən inkişaf prinsipidir. Bu o deməkdir ki, hər bir məntiq, konfiqurasiya və ya metadataset tam olaraq bir yerdə mövcud olmalıdır.

Termin Endi Hant və Deyv Tomas tərəfindən 1999-cu ildə “The Pragmatic Programmer” kitabında təqdim edilmişdir. Müəlliflər DRY-ni “hər bir bilik parçası sistemdə tək, ardıcıl təmsilə malik olmalıdır” kimi təyin etmişlər. DRY-nin əksi — təkrarlanmanın norma hesab edildiyi WET (Write Everything Twice) yanaşmasıdır.

University of California, Davis (2019) tədqiqatına görə, yüksək kod təkrarlanması olan layihələr xətaların düzəldilməsinə 42% daha çox vaxt sərf edir. Səbəb odur ki, tərtibatçı eyni fraqmentin bütün nüsxələrini tapıb dəyişməlidir — əl ilə axtarışda buraxılışlar qaçılmazdır.

DRY-ni kod keyfiyyəti meyarı kimi tətbiq edin. Əgər eyni nümunənin layihədə üç dəfə göründüyünü görürsünüzsə — dördüncü təkrarlanmanı gözləmədən onu abstraksiyaya ayırın.

DRY-nin tək məsuliyyət prinsipindən fərqi

Single Responsibility Principle (SRP) SOLID-dən bildirir ki, bir sinfin dəyişmək üçün bir səbəbi olmalıdır. DRY daha genişdir: o, təkcə sinifləri deyil, həm də məlumatları, konfiqurasiyanı, sənədləşməni və hətta biznes qaydalarını əhatə edir. SRP məsuliyyət sərhədləri haqqındadır, DRY — kopyalamanın yolverilməzliyi haqqında.

Mobil inkişafda bu fərq xüsusilə nəzərə çarpır. Əgər eyni biznes qaydası (vergi hesablanması, tarix formatlaması) Android və iOS hissələrində təkrarlanırsa — bu DRY-nin pozulmasıdır, baxmayaraq ki, SRP formal olaraq hər platforma daxilində qorunur. Həll yolu — ümumi məntiqi paylaşılan modula (KMM, C++) ayırmaq.

Google Android Architecture Guidelines (2023) hesabatına görə, biznes məntiqi üçün ümumi modullardan istifadə edən komandalar tələblər dəyişdikdə xəta sayını platformalar arasında təkrarlanan məntiqi olan layihələrlə müqayisədə 37% azaldır.

Kod təkrarlanması niyə təhlükəlidir?

Təkrarlanma — mobil layihələrdə texniki borcun əsas mənbəyidir. Hər bir kod nüsxəsi gizli asılılıq yaradır: davranışı dəyişmək üçün bütün nüsxələri tapmaq və yeniləmək lazımdır. Heç olmasa birini buraxmaq xəta deməkdir.

Klassik vəziyyəti nəzərdən keçirək: Android tətbiqində tarix formatlaması üç fərqli Activity-də yerinə yetirilir. Yeni formata (məsələn, ISO 8601) keçid zamanı tərtibatçı iki faylı düzəldir, üçüncünü unudur — və istifadəçi tarixi köhnə formatda görür. Tətbiqin reytinqi düşür və xətanın axtarışı iki dəfə çox vaxt aparır.

Google Research (2020) tədqiqatı göstərdi: mobil tətbiqlərdə kritik xətaların 68%-i təkrarlanan kodun sinxron olmayan dəyişdirilməsi ilə bağlıdır. Belə bir xətanın production-da düzəldilməsinin dəyəri kod əvvəldən vahid olsaydı, 4,5 dəfə yüksəkdir.

Copy-paste aşkarlanmasını qadağan edən qaydalarla statik analizatordan (Detekt, SwiftLint) istifadə edin. CI-ni elə konfiqurasiya edin ki, N sətirdən çox təkrarlanması olan pull-requestlər əsaslandırılmadan review-dən keçməsin.

DRY mobil inkişafda: praktiki nümunələr

Android-də UI məntiqinin təkrarlanması

Tipik anti-nümunə — RecyclerView adapterinin cüzi dəyişikliklərlə kopyalanması. Konfiqurasiyalı bir universal adapter əvəzinə tərtibatçılar hər ekran üçün ayrıca sinif yaradırlar. Ümumi baza sinfinin ayrılması ilə refaktorinq kodu 30–50% qısaldır.

// Təkrarlanma: iki ayrı adapter
class UserAdapter {
    fun bind(item: User) { /* ... */ }
}
class ProductAdapter {
    fun bind(item: Product) { /* ... */ }
}

// DRY-refaktorinq: ümumi baza sinfi
abstract class BaseAdapter<T> {
    abstract fun bind(item: T)
}
class UserAdapter : BaseAdapter<User>() { /* ... */ }
class ProductAdapter : BaseAdapter<Product>() { /* ... */ }

Birinci nümunədə hər adapter bind mexanizmini yenidən tətbiq edir. Yeni məntiq (analitika, loqlama) əlavə edilərkən hər faylı dəyişmək lazım gələrdi. Baza sinfi bu təkrarlanmanı aradan qaldırır: ümumi məntiq bir yerdə, spesifik olan isə varislərdə yaşayır.

iOS-da şəbəkə sorğularının təkrarlanması

iOS layihələrində URLSession konfiqurasiyası — başlıqlar, vaxt limitləri, xəta idarəetməsi tez-tez təkrarlanır. Hər bir xidmət təkrarlanan parametrlərlə öz sessiyasını yaradır.

// Təkrarlanma: hər xidmət sessiyanı yenidən konfiqurasiya edir
class UserService {
    let session = URLSession(configuration: {
        let cfg = URLSessionConfiguration.default
        cfg.timeoutIntervalForRequest = 30
        cfg.httpAdditionalHeaders = ["Authorization": "Bearer ..."]
        return cfg
    }())
}

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

Konfiqurasiyanın vahid NetworkConfig-ə ayrılması bütün xidmətlərin eyni başlıqları və vaxt limitlərini istifadə etməsini təmin edir. Bir yerdə dəyişiklik avtomatik olaraq bütün sorğulara tətbiq edilir — bu, API açarı və ya protokol versiyası dəyişikliyində xəta riskini azaldır.

Android və iOS-da DRY necə tətbiq edilir?

Miras və kompozisiya vasitəsilə DRY

Miras — təkrarlanmanı aradan qaldırmağın təbii yolu: ümumi məntiq baza sinfinə, spesifik olan isə varislərə ayrılır. Lakin mobil inkişafda mirasdan sui-istifadə çətin dəstəklənən sərt iyerarxiyalar yaradır. Kompozisiya (asılılıq inyeksiyası) — daha çevik alternativdir.

Google I/O 2023: Modern Android Architecture təhlili göstərdi ki, Google komandalarının 76%-i təkrarlanmanı aradan qaldırmaq üçün miras əvəzinə kompozisiyaya üstünlük verir. On metodlu BaseViewModel əvəzinə hər biznes əməliyyatı üçün ayrıca UseCase siniflərinin ayrılması və lazım olduğu yerdə inyeksiya edilməsi tövsiyə olunur.

Bütün hallarda, “is-a” münasibətləri istisna olmaqla, kompozisiyanı seçin. Əgər A sinfi B sinfinin ixtisaslaşmasıdırsa — miras uyğundur. Əgər A sadəcə B-nin funksionallığından istifadə edirsə — kompozisiyadan istifadə edin.

Köməkçi siniflər vasitəsilə DRY

Köməkçi siniflər (Extensions, Helpers) — təkrarlanmadan qaçmağın ən sadə yoludur. Tipik namizədlər: tarix formatlaması, email validasiyası, vahid konvertasiyası, SharedPreferences/UserDefaults ilə iş.

// DRY: vahid tarix formatlama funksiyası
fun Date.toDisplayFormat(): String {
    val sdf = SimpleDateFormat("dd.MM.yyyy", Locale.getDefault())
    return sdf.format(this)
}

// Tətbiqin istənilən yerində istifadə
textView.text = Date().toDisplayFormat()

Date.toDisplayFormat() genişləndirməsi bir dəfə elan edilir və bütün layihədə əlçatandır. Formatı “dd.MM.yyyy”-dən “yyyy-MM-dd”-yə dəyişmək lazım gəlsə — düzəliş bir faylda, formatlamanın göründüyü hər Activity və ya Fragment-də deyil. Bu məhz DRY-nin mahiyyətidir.

Gradle konfiqurasiyasında DRY (Android)

Çoxmodullu Android layihələri tez-tez hər build.gradle faylında asılılıq versiyalarını təkrarlayır. Həll yolu — bütün versiyaları bir faylda mərkəzləşdirən version catalog (libs.versions.toml).

Android Developer Documentation (2024)-ə görə, version catalog-a miqrasiya asılılıq konfliktlərini 52% azaldır və vahid düzəliş nöqtəsi sayəsində qurulmanı sürətləndirir.

Version catalog-u layihənin əvvəlində və ya modulların ilk reorganizasiyası zamanı tətbiq edin. Əgər layihədə artıq təkrarlanma varsa — miqrasiya üçün bir gün ayırın: bu, kitabxanaların növbəti yenilənməsində özünü doğruldacaq.

DRY-yə əməl edərkən tipik səhvlər

Vaxtından əvvəl abstraksiya

Vaxtından əvvəl abstraksiya — yeni başlayanların ən çox etdiyi səhvdir. Tərtibatçı iki oxşar kod sətiri görür və dərhal onları ümumi funksiyaya ayırır. Bir aydan sonra tələblər dəyişir və ümumi funksiya parametrlər və flaq'larla yüklənir — ilkin təkrarlanmadan daha mürəkkəb olur. Rule of Three məhz bundan qoruyur: bir-iki dəfə rast gəlinəni abstraksiya etməyin.

Martin Fauler Refactoring (2019) kitabında tövsiyə edir: “Kodun təkrarlanması həmişə pis deyil. Bilginin təkrarlanması pisdir”. Əgər iki sətir təsadüfən üst-üstə düşürsə, lakin fərqli konsepsiyaları ifadə edirsə — bu təkrarlanma deyil, təsadüfdür. Rule of Three təsadüfi üst-üstə düşməni sistematik təkrarlanmadan ayırmağa kömək edir.

Abstraksiya etməzdən əvvəl semantikanı qiymətləndirin. Eyni mənalı kopyalanmış kod — DRY-nin pozulmasıdır. Fərqli mənalı, lakin oxşar sintaksisli kod — abstraksiya tələb etməyən təsadüfdür.

Həddindən artıq parametrləşdirmə

Həddindən artıq parametrləşdirmə bir funksiyanın bütün mümkün ssenariləri flaq və boolean parametrlər vasitəsilə əhatə etməyə çalışdıqda yaranır. Belə kod SRP-ni pozur və oxunmaz olur. Əlamət: funksiyanın ikidən çox boolean parametri varsa — bu, həddindən artıq abstraksiya qoxusudur (code smell).

useCache: Boolean flaq'lı bir funksiya əvəzinə iki ayrı funksiya yaratmaq daha yaxşıdır: fetchFromNetwork() və fetchFromCache(). Aşkarlıq quru abstraksiyadan daha vacibdir — bu KISS prinsipi ilə uzlaşır.

Funksiya 3+ boolean parametrə çatdıqda həddindən artıq parametrləşdirməni refaktor edin. Aydın adlarla ayrıca funksiyalara bölün — hər çağırış öz-özünü sənədləşdirən olacaq.