Mobil Geliştirmede Mimari İlkeler: Nedir, Türleri Nelerdir ve Nasıl Uygulanır

SOLID İlkeleri

Mimari ilkeler — kaliteli kodun temelidir. SOLID, Robert Martin («Bob Amca») tarafından tanıtılan ve nesne yönelimli tasarımın beş ilkesini tanımlayan bir kısaltmadır. SOLID'i takip etmek kodu daha esnek, test edilebilir ve değişikliklere karşı dayanıklı hale getirir. Mimari ilkelerin ihlali, teknik borcun ana nedenlerinden biridir.

Her ilkeyi inceleyelim. Single Responsibility Principle (SRP) — her sınıfın değişiklik için yalnızca bir nedeni olmalıdır. Open/Closed Principle (OCP) — sınıflar genişletmeye açık, ancak değişikliğe kapalı olmalıdır. Liskov Substitution Principle (LSP) — alt türlerin nesneleri, mantığı bozmadan temel türün nesnelerini değiştirebilmelidir. Interface Segregation Principle (ISP) — tek bir genel arayüzdense birçok özelleşmiş arayüz daha iyidir. Dependency Inversion Principle (DIP) — somut uygulamalara değil, soyutlamalara bağımlı olun.

SonarQube analizine (2025) göre, SOLID ilkelerinin ihlali ticari projelerin %68'inde görülür. En yaygın sorunlar SRP ihlali (%35) ve ISP ihlalidir (%22). IT Sectr'da, SOLID'i mimari inceleme aşamasında uyguluyoruz — bu, sorunların teknik borca dönüşmeden önce tespit edilmesine yardımcı olur.

Single Responsibility Principle (SRP)

SRP (Tek Sorumluluk İlkesi) — en önemli ve aynı zamanda en sık ihlal edilen SOLID ilkesidir. Şunu belirtir: bir sınıfın değişiklik için yalnızca bir nedeni olmalıdır. Bir sınıf çok fazla iş yapıyorsa, test etmesi, değiştirmesi ve anlaması zordur.

Tipik bir ihlal, aynı anda verileri işleyen, veritabanına kaydeden ve e-posta bildirimleri gönderen bir sınıftır. Aşağıdaki örnek, Kotlin'de SRP ihlalini ve nasıl düzeltileceğini gösterir.

// SRP ihlali — sınıf üç farklı iş yapıyor
class UserService {
    fun registerUser(email: String, name: String) {
        // 1. Veri doğrulama
        if (!email.contains("@")) throw IllegalArgumentException("Invalid email")
        
        // 2. Veritabanına kaydet
        val user = User(email, name)
        database.save(user)
        
        // 3. Bildirim gönder
        emailService.sendWelcomeEmail(email, name)
    }
}

// Düzeltme — üç sınıfa ayırma
class UserRegistrationService {
    fun register(email: String, name: String) {
        UserValidator().validate(email)
        val user = User(email, name)
        UserRepository().save(user)
        NotificationService().sendWelcome(user)
    }
}

Düzeltilmiş sürümde, her sınıf kendi görevinden sorumludur: UserValidator — doğrulamadan, UserRepository — kaydetmeden, NotificationService — bildirimlerden. Bu, kodu test edilebilir ve yeniden kullanılabilir hale getirir — doğrulama mantığını değiştirmeden veritabanı uygulamasını değiştirebilirsiniz.

GRASP ve Law of Demeter

GRASP (General Responsibility Assignment Software Patterns) — Craig Larman tarafından tanımlanan, nesneler arasında sorumluluk dağıtımı için dokuz mimari ilke. SOLID'den farklı olarak GRASP, «hangi sınıf bu metodu içermeli?» sorusuna yanıt verir. Ana desenler: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations.

Law of Demeter (LoD, minimum bağlantı ilkesi) — basit bir kural: bir nesne yalnızca doğrudan komşularıyla iletişim kurmalıdır. a.getB().getC().doSomething() yazılmamalıdır — bu, sınıflar arasında güçlü bağlantı oluşturur. LoD, yeniden kullanılabilirliği artırır ve test etmeyi basitleştirir.

IT Sectr'da, Kod İncelemesi sırasında LoD uyumluluğunu kontrol ederiz. Bir metot üç veya daha fazla nesneden «geçiyorsa», bu mimarinin basitleştirilmesi gerektiğine dair bir işarettir. LoD ihlali, büyük projelerde en yaygın Code Smell'lerden biridir.

DRY / KISS / YAGNI

DRY (Don't Repeat Yourself), KISS (Keep It Simple, Stupid) ve YAGNI (You Ain't Gonna Need It) — her geliştiricinin bildiği üç temel mimari ilke. Basitliklerine rağmen, ihlaller sürekli olarak meydana gelir.

DRY — kodu tekrarlamayın. Aynı mantık iki yerde görünüyorsa, onu ortak bir metoda veya sınıfa çıkarın. Tekrarlama, hataların ana kaynağıdır: bir yerdeki düzeltme başka bir yerde uygulanmayı unutulur. DRY, benzer koda sahip olamayacağınız anlamına gelmez — önemli olan iş mantığının tekrarlanmamasıdır.

KISS — ne kadar basit, o kadar iyi. Birçok soyutlama ve kalıtım içeren karmaşık çözümler genellikle aşırıdır. Basit bir çözümle başlayın ve yalnızca gerektiğinde karmaşıklaştırın. YAGNI — «bir gün sonra» gerekebilecek işlevler için kod yazmayın. Bu, kod tabanının şişmesine ve bakım karmaşıklığının artmasına yol açar.

DRY — Don't Repeat Yourself

DRY — bu sadece kopyala-yapıştırın olmaması değildir. Bu, bilgi veya mantığın her parçasının sistemde tek, açık bir temsile sahip olması gerektiği ilkesidir. Tekrarlama açık (kopyalanmış kod) ve örtük (farklı katmanlarda aynı mantık) olabilir.

IT Sectr'da, tekrarlamayı tespit etmek için kod analizi metrikleri kullanırız. SonarQube ve Detekt gibi araçlar, tekrarlanan kodun yüzdesini gösterir. %5'in üzerindeki bir değer, yeniden düzenleme için bir nedendir. Ancak, DRY'nin yanlış soyutlamalar pahasına elde edilmemesi gerektiğini hatırlamak önemlidir — bazen iki benzer kod parçasını birleştirmek anlamayı zorlaştıracaksa olduğu gibi bırakmak daha iyidir.

Separation of Concerns ve Modularity

Separation of Concerns (SoC) — bir sistemin bağımsız parçalara (concerns) ayrıldığı, her birinin kendi görevini çözdüğü bir mimari ilkedir. Klasik bir örnek, katmanlara ayrılmadır: sunum, iş mantığı, veri erişimi. Her katman yalnızca altındaki katmana bağımlıdır.

Modularity (modülerlik) — bir sistemin modüllere bölünebilme derecesidir. Modül, iyi tanımlanmış bir arayüze sahip, mantıksal olarak ilişkili sınıflar grubudur. Modüller gevşek bağlı (düşük coupling) ve yüksek bağdaşıklığa (yüksek cohesion) sahip olmalıdır.

Cohesion vs Coupling

Cohesion (bağdaşıklık) — aynı modül içindeki öğelerin birbiriyle ne kadar ilişkili olduğunun bir ölçüsüdür. Yüksek bağdaşıklık iyidir: bir sınıf tek bir şey yapar ve onu iyi yapar. Düşük coupling (bağlılık) — modüllerin birbirinden ne kadar bağımsız olduğunun bir ölçüsüdür. Düşük bağlılık iyidir: bir modüldeki değişiklik diğerlerini bozmaz.

İdeal mimari, yüksek bağdaşıklık ve düşük bağlılıktır. Pratikte bu, bir sınıfın aynı veriler üzerinde çalışan metotlar içerdiği (bağdaşıklık) ve yalnızca soyutlamalara bağımlı olduğu, somut uygulamalara değil (bağlılık) anlamına gelir. Dengesizlik, «Tanrı Nesneleri» veya «spagetti kod»a yol açar.

Teknik Borç ve Code Smell

Teknik borç (Technical Debt) — Ward Cunningham tarafından tanıtılan, bir ekibin optimal olmayan mimari kararlar ve mimari ilkelerin ihlali için ödediği «faizi» tanımlayan bir metafor. Finansal borç gibi, teknik borç da kasıtlı (hızlı yapmaya karar verdik, sonra yeniden yaparız) ve kasıtsız (deneyim eksikliği nedeniyle kötü mimari) olabilir.

Code Smell — koddaki derin sorunların yüzeysel işaretleridir. Terim, Martin Fowler tarafından «Refactoring» kitabında popüler hale getirilmiştir. Tipik Code Smell'ler: uzun metotlar, büyük sınıflar, uzun çağrı zincirleri, kod tekrarı, aşırı yorum kullanımı (net kod yerine).

IT Sectr'da, teknik borç Jira'da ayrı görevler olarak takip edilir. Her sprintte, yeniden düzenleme ve borç ödemesi için zamanın %20'sini ayırırız. Teknik borçla sistematik çalışma, yeni bir özellik eklemenin sıfırdan geliştirmekten daha uzun sürdüğü bir durumdan kaçınmanın tek yoludur.