Mobil geliştirmede DRY — nedir, ilkesi ve tekrarın neden zararlı olduğu

DRY nedir?

DRY (Don't Repeat Yourself), bir projedeki her bilgi öğesini tam olarak bir kez depolamayı gerektiren bir geliştirme ilkesidir. Bu, herhangi bir mantık, yapılandırma veya meta verinin yalnızca tek bir yerde bulunması gerektiği anlamına gelir.

Terim, Andy Hunt ve Dave Thomas tarafından 1999'da “The Pragmatic Programmer” kitabında tanıtıldı. Yazarlar DRY'yi “bilginin her parçası sistem içinde tek, açık ve yetkili bir temsile sahip olmalıdır” şeklinde tanımladı. DRY'nin zıttı, tekrarın normal kabul edildiği WET (Write Everything Twice) yaklaşımıdır.

University of California, Davis (2019) tarafından yapılan bir araştırmaya göre, yüksek düzeyde kod tekrarı olan projeler hata düzeltmede %42 daha fazla zaman harcar. Bunun nedeni, geliştiricilerin aynı parçanın tüm kopyalarını bulup değiştirmesi gerektiğinden ve manuel aramanın kaçınılmaz olarak atlamalara yol açmasıdır.

DRY'yi bir kod kalitesi kriteri olarak uygulayın. Aynı desenin bir projede üç kez göründüğünü fark ederseniz, dördüncü tekrarı beklemeden onu bir soyutlamaya çıkarın.

DRY ve tek sorumluluk ilkesi arasındaki fark

SOLID'den Tek Sorumluluk İlkesi (SRP), bir sınıfın değişiklik için tek bir nedeni olması gerektiğini belirtir. DRY daha geniştir: yalnızca sınıfları değil, aynı zamanda verileri, yapılandırmayı, belgeleri ve hatta iş kurallarını da kapsar. SRP sorumluluk sınırlarıyla ilgilidir; DRY kopyalamayı önlemeyle ilgilidir.

Mobil geliştirmede bu ayrım özellikle belirgindir. Aynı iş kuralı (vergi hesaplama, tarih biçimlendirme) projenin hem Android hem de iOS bölümlerinde tekrarlanıyorsa — bu, SRP her platform içinde resmi olarak gözlemlense bile bir DRY ihlalidir. Çözüm, ortak mantığı paylaşılan bir modüle (KMM, C++) çıkarmaktır.

Google Android Architecture Guidelines (2023) raporuna göre, iş mantığı için paylaşılan modüller kullanan ekipler, platformlar arasında mantığı tekrarlayan projelere kıyasla gereksinim değişikliklerinde hata sayısını %37 azaltır.

Kod tekrarı neden tehlikelidir?

Tekrar, mobil projelerde teknik borcun ana kaynağıdır. Her kod kopyası gizli bir bağımlılık oluşturur: davranışı değiştirmek için tüm kopyaları bulup güncellemeniz gerekir. Birini bile kaçırmak bir hatadır.

Klasik bir senaryo düşünün: bir Android uygulamasında, tarih biçimlendirme üç farklı Activity'de yapılır. Yeni bir biçime (örneğin, ISO 8601) geçerken, geliştirici iki dosyayı düzeltir, üçüncüyü unutur — ve kullanıcı tarihleri eski biçimde görür. Uygulama puanı düşer ve hatayı bulmak iki kat daha uzun sürer.

Google Research (2020) tarafından yapılan bir araştırma, mobil uygulamalardaki kritik hataların %68'inin tekrarlanan koddaki eşzamanlı olmayan değişikliklerle ilgili olduğunu gösterdi. Ayrıca, üretimde böyle bir hatayı düzeltmek, kod baştan itibaren birleştirilmiş olsaydı olacağından 4,5 kat daha pahalıdır.

Copy-paste'i tespit eden kurallarla statik analizörler (Detekt, SwiftLint) kullanın. CI'yi, N satırdan fazla tekrar içeren çekme isteklerinin gerekçesiz olarak incelemeyi geçemeyeceği şekilde yapılandırın.

Mobil geliştirmede DRY: pratik örnekler

Android'de UI mantığının tekrarı

Tipik bir anti-desen, küçük değişikliklerle bir RecyclerView bağdaştırıcısını kopyalamaktır. Evrensel bir bağdaştırıcı yerine, geliştiriciler her ekran için ayrı bir sınıf oluşturur. Ortak bir temel sınıf çıkararak yeniden düzenleme, kodu %30–50 oranında azaltır.

// Tekrar: iki ayrı bağdaştırıcı
class UserAdapter {
    fun bind(item: User) { /* ... */ }
}
class ProductAdapter {
    fun bind(item: Product) { /* ... */ }
}

// DRY yeniden düzenleme: ortak temel sınıf
abstract class BaseAdapter<T> {
    abstract fun bind(item: T)
}
class UserAdapter : BaseAdapter<User>() { /* ... */ }
class ProductAdapter : BaseAdapter<Product>() { /* ... */ }

İlk örnekte, her bağdaştırıcı bağlama mekanizmasını sıfırdan yeniden uygular. Yeni mantık (analitik, günlükleme) eklerken her dosyanın değiştirilmesi gerekir. Bir temel sınıf bu tekrarı ortadan kaldırır: ortak mantık tek bir yerde, belirli mantık alt sınıflarda yaşar.

iOS'ta ağ isteklerinin tekrarı

iOS projelerinde, URLSession yapılandırması — başlıklar, zaman aşımları, hata işleme — sıklıkla tekrarlanır. Her hizmet, yinelenen ayarlarla kendi oturumunu oluşturur.

// Tekrar: her hizmet oturumu yeniden yapılandırır
class UserService {
    let session = URLSession(configuration: {
        let cfg = URLSessionConfiguration.default
        cfg.timeoutIntervalForRequest = 30
        cfg.httpAdditionalHeaders = ["Authorization": "Bearer ..."]
        return cfg
    }())
}

// DRY: birleşik oturum fabrikası
struct NetworkConfig {
    static var session: URLSession {
        let cfg = URLSessionConfiguration.default
        cfg.timeoutIntervalForRequest = 30
        cfg.httpAdditionalHeaders = ["Authorization": "Bearer ..."]
        return URLSession(configuration: cfg)
    }
}

Yapılandırmayı birleşik bir NetworkConfig'e çıkarmak, tüm hizmetlerin aynı başlıkları ve zaman aşımlarını kullanmasını sağlar. Bir yerdeki değişiklik otomatik olarak tüm isteklere uygulanır — bu, API anahtarlarını veya protokol sürümlerini değiştirirken hata riskini azaltır.

Android ve iOS'ta DRY nasıl uygulanır?

Kalıtım ve kompozisyon yoluyla DRY

Kalıtım, tekrarı ortadan kaldırmanın doğal bir yoludur: ortak mantık bir temel sınıfa, belirli mantık alt sınıflara taşınır. Ancak mobil geliştirmede, kalıtımın aşırı kullanımı bakımı zor, katı hiyerarşiler oluşturur. Kompozisyon (bağımlılık enjeksiyonu) daha esnek bir alternatiftir.

Google I/O 2023: Modern Android Architecture'dan yapılan bir analiz, Google ekiplerinin %76'sının tekrarı ortadan kaldırmak için kalıtım yerine kompozisyonu tercih ettiğini gösterdi. Bir düzine yöntemi olan bir BaseViewModel yerine, her iş işlemi için ayrı UseCase sınıfları çıkarılması ve ihtiyaç duyulan yerlere enjekte edilmesi önerilir.

“Bir-şudur” ilişkileri dışındaki tüm durumlarda kompozisyonu seçin. A sınıfı, B sınıfının bir uzmanlaşmasıysa — kalıtım uygundur. A yalnızca B'nin işlevselliğini kullanıyorsa — kompozisyon kullanın.

Yardımcı sınıflar yoluyla DRY

Yardımcı sınıflar (Extensions, Helpers), tekrardan kaçınmanın en basit yoludur. Tipik adaylar: tarih biçimlendirme, e-posta doğrulama, birim dönüştürme, SharedPreferences/UserDefaults ile çalışma.

// DRY: birleşik tarih biçimlendirme fonksiyonu
fun Date.toDisplayFormat(): String {
    val sdf = SimpleDateFormat("dd.MM.yyyy", Locale.getDefault())
    return sdf.format(this)
}

// Uygulamanın her yerinde kullanım
textView.text = Date().toDisplayFormat()

Date.toDisplayFormat() uzantısı bir kez bildirilir ve proje genelinde kullanılabilir. Biçimin “dd.MM.yyyy”den “yyyy-MM-dd”ye değiştirilmesi gerekiyorsa — düzeltme tek bir dosyadadır, biçimlendirmenin gerçekleştiği her Activity veya Fragment'te değil. İşte DRY'nin özü budur.

Gradle yapılandırmasında DRY (Android)

Çok modüllü Android projeleri genellikle her build.gradle'da bağımlılık sürümlerini tekrarlar. Çözüm, tüm sürümleri tek bir dosyada merkezileştiren bir sürüm kataloğudur (libs.versions.toml).

Android Geliştirici Belgelerine (2024) göre, bir sürüm kataloğuna geçiş, bağımlılık çakışmalarını %52 azaltır ve tek bir düzenleme noktasıyla derlemeleri hızlandırır.

Proje başlangıcında veya ilk modül yeniden yapılanması sırasında bir sürüm kataloğu uygulayın. Proje zaten tekrar içeriyorsa — geçiş için bir gün ayırın: bir sonraki kütüphane güncellemesinde kendini amorti edecektir.

DRY'yi takip ederken tipik hatalar

Erken soyutlama

Erken soyutlama, yeni başlayanların en yaygın hatasıdır. Bir geliştirici iki benzer kod satırı görür ve hemen onları ortak bir fonksiyona çıkarır. Bir ay sonra gereksinimler değişir ve ortak fonksiyon parametreler ve bayraklarla dolup taşar — orijinal tekrardan daha karmaşık hale gelir. Üç Kuralı tam olarak buna karşı korur: yalnızca bir veya iki kez ortaya çıkan bir şeyi soyutlamayın.

Martin Fowler, Refactoring (2019) kitabında şunları önerir: “Kod tekrarı her zaman kötü değildir. Bilgi tekrarı kötüdür.” İki satır tesadüfen eşleşiyor ancak farklı kavramları ifade ediyorsa — bu tekrar değil, tesadüftür. Üç Kuralı, tesadüfi tesadüfü sistematik tekrardan ayırt etmeye yardımcı olur.

Soyutlamadan önce anlamı değerlendirin. Aynı anlamla kopyalanan kod — DRY ihlali. Farklı anlam ancak benzer sözdizimi olan kod — soyutlama gerektirmeyen tesadüf.

Aşırı parametrelendirme

Aşırı parametrelendirme, tek bir fonksiyonun bayraklar ve boolean parametreler aracılığıyla tüm olası senaryoları kapsamaya çalışmasıyla oluşur. Bu tür kod SRP'yi ihlal eder ve okunamaz hale gelir. Belirti: bir fonksiyonda ikiden fazla boolean parametre varsa — bu aşırı soyutlamanın kod kokusudur.

useCache: Boolean bayrağı olan tek bir fonksiyon yerine, net adlara sahip iki ayrı fonksiyon oluşturmak daha iyidir: fetchFromNetwork() ve fetchFromCache(). Açıklık kuru bir soyutlamadan daha önemlidir — bu KISS ilkesiyle örtüşür.

Bir fonksiyon 3+ boolean parametreye ulaştığında aşırı parametrelendirmeyi yeniden düzenleyin. Net adlara sahip ayrı fonksiyonlara bölün — her çağrı kendi kendini belgeleyen hale gelir.