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

Ana Mimari Desenler

Mimari desen, sorumlulukların uygulama sınıfları arasında nasıl dağıtılacağını belirler. Desen seçimi, yeni ekranlar ekleme ve kodu test etme kolaylığını etkiler.

MVC (Model-View-Controller)

MVC, Model'in verileri, View'in görüntülemeyi ve Controller'ın mantığı yönettiği klasik bir desendir. iOS'ta MVC varsayılandır (UIViewController); Android'de Activity'dir. Dezavantajı, Controller'ın genellikle "büyük" (Massive View Controller) hale gelmesidir. Bir iOS geliştirici anketine (Reddit, 2025) göre, %62'si eski projelerde okunamaz kodun ana nedeni olarak MVC'yi göstermektedir.

MVP (Model-View-Presenter)

MVP, Presenter'ın View'i bir arayüz aracılığıyla yönetmesiyle farklılaşır ve test edilebilirliği artırır. MVP, Jetpack'ten önce Android'de popülerdi ancak kullanışlılık açısından MVVM'nin gerisindedir.

MVVM (Model-View-ViewModel)

MVVM, Google tarafından Android ve Apple tarafından iOS için önerilen desendir. ViewModel durumu depolar ve View, Data Binding veya @Published aracılığıyla değişikliklere abone olur. ViewModel, View'a bağımlı değildir ve test edilmesi kolaydır. IT Sectr'de tüm projelerde ana desen olarak MVVM kullanıyoruz.

MVI ve VIPER

MVI, her eylemin Intent → Model → View döngüsünü izlediği reaktif bir desendir. MVI, öngörülebilir durum sağlar. VIPER, beş katmanlı (View, Interactor, Presenter, Entity, Router) bir iOS desenidir ve maksimum izolasyon sağlar ancak çok fazla kalıp kodu gerektirir.

Clean Architecture

Clean Architecture, Robert Martin'in bir uygulamayı katmanlara ayıran konseptidir: dış katmanlar (UI, DB, ağ) iç katmanlara (iş mantığı, varlıklar) bağımlıdır. Mobil geliştirmede Clean Architecture üç katman içerir: data (depolar), domain (Use Cases) ve presentation (ViewModels, UI).

Repository Pattern, Clean Architecture'ın veri kaynağını soyutlayan anahtar bileşenidir. Depo, verileri ağdan mı yoksa yerel depolamadan mı (Room, Core Data) alacağına karar verir ve birleşik bir biçim döndürür. Google'a (Architecture Guide, 2025) göre Repository Pattern, ağ istekleri olan her uygulama için önerilir. Clean Architecture, 3–5 ekran veya daha fazla olan projelerde haklı çıkar — basit uygulamalar için MVVM ile başlayın.

Oluşturucu Desenler

Singleton

Singleton, bir sınıfın tek bir örneğini garanti eden ve ona genel bir erişim noktası sağlayan mimari bir desendir. Veritabanları, ayar yöneticileri ve önbellek için kullanılır. Kotlin'de object aracılığıyla oluşturulur. Dezavantajı, genel durum nedeniyle testi zorlaştırmasıdır.

Factory ve Builder

Factory, nesne oluşturmayı bir fabrika yöntemine devreder — new yerine fabrikayı çağırırsınız. Builder, çok sayıda parametreye sahip karmaşık nesneler (AlertDialog.Builder, NotificationCompat.Builder) için adım adım oluşturma desenidir. Builder, okunabilirliği artırır ve nesnelerin birleştirmeden sonra değişmez kalmasını sağlar.

Yapısal ve Davranışsal Desenler

Adapter, Facade, Delegate, Protocol

Adapter, bir sınıfın arayüzünü istemcinin beklediği arayüze dönüştüren mimari bir desendir. Android'de bu RecyclerView.Adapter'dır. Facade, karmaşık bir sisteme basitleştirilmiş bir arayüz sağlar — örneğin, kimlik doğrulama ayrıntılarını gizleyen bir API için cephe. Delegate, bir nesnenin görevi devrettiği iOS desenidir (UITableViewDelegate). Protocol, Swift'teki arayüzün eşdeğeridir.

Observer ve Strategy

Observer, değişiklikler için abonelik desenidir: konu, aboneleri güncellemeler hakkında bilgilendirir. Mobil geliştirmede Observer, LiveData, StateFlow, RxJava ve Combine'ın temelidir. Strategy, değiştirilebilir algoritmalar desenidir: birden çok if-else ifadesi olmadan farklı bir strateji (sıralama, doğrulama) eklersiniz.

Bağımlılık Enjeksiyonu ve Durum Yönetimi

Dependency Injection, bir nesnenin bağımlılıklarını kendisi oluşturmak yerine dışarıdan aldığı mimari bir desendir. new Database() yerine, veritabanını yapıcı aracılığıyla iletirsiniz. DI, testi basitleştirir — gerçek veritabanı yerine Mock kullanabilirsiniz — ve uygulamaların değiştirilmesini kolaylaştırır. Popüler DI çerçeveleri: Dagger ve Hilt (Android), Swinject (iOS), Koin (Kotlin). Google tarafından önerilen Dagger üzerine bir sarmalayıcı olan Hilt, DI kurulumunu 3 kat azaltır.

Service Locator, merkezi bir bağımlılık kaydına sahip DI alternatifidir. Uygulaması daha basittir ancak sınıf bağımlılıklarını gizleyerek testi zorlaştırır. Modern projeler Hilt veya Koin aracılığıyla DI'yı tercih eder.

Flutter'da Durum Yönetimi

Flutter'da durum yönetimi kendi ekosistemidir. Redux — Actions → Reducer → State aracılığıyla değişikliklerin olduğu tek bir Store. Google'ın BLoC'u, Stream aracılığıyla olayları ve durumları ayırır. Provider — 2023'e kadar Google tarafından Flutter için önerilen basit bir DI kabı. Riverpod — derleme ve test sorunlarını çözen geliştirilmiş bir Provider. GetX — yönlendirme, DI ve durum yönetimi içeren bir mikro çerçeve. Yeni başlayan Flutter geliştiricileri için en iyi belgelenmiş çözümler olarak Provider veya Riverpod'u öneriyoruz.

SOLID ve DRY İlkeleri

Belirli desenlerin yanı sıra, her dilde ve çerçevede uygulanabilir genel mimari tasarım ilkeleri vardır.

SOLID — nesne yönelimli tasarımın beş ilkesi: Single Responsibility (bir sınıf — bir görev), Open-Closed (genişletmeye açık, değiştirmeye kapalı), Liskov Substitution (alt sınıflar üst sınıfın yerini alabilir), Interface Segregation (küçük arayüzler), Dependency Inversion (soyutlamalara bağımlılık). Mobil geliştirmede SRP en kullanışlı ilkedir: her sınıf yalnızca bir şey yapar. IT Sectr deneyimine göre, SRP ihlali ticari projelerdeki test sorunlarının %70'inin nedenidir.

// Пример: нарушение SRP
class UserManager {
    fun saveUser(user: User) { /* сохранение */ }
    fun validateEmail(email: String): Boolean { /* валидация */ }
    fun sendEmail(user: User) { /* отправка */ }
    fun formatUser(user: User): String { /* форматирование */ }
}

// Исправление: разделяем на отдельные классы
class UserRepository { fun save(user: User) {} }
class EmailValidator { fun isValid(email: String): Boolean {} }
class EmailService { fun send(user: User) {} }
class UserFormatter { fun format(user: User): String {} }

Kotlin örneği, dört sorumluluğu olan bir UserManager sınıfını, her biri bir sorumluluğa sahip dört sınıfa nasıl dönüştürdüğümüzü gösterir. Bu tür kodların test edilmesi, değiştirilmesi ve yeniden kullanılması daha kolaydır.

DRY (Don't Repeat Yourself) — kod tekrarından kaçının. Tekrarlanan mantığı paylaşılan yöntemlere veya sınıflara çıkarın. KISS (Keep It Simple, Stupid) — basitlik, zarafetten daha önemlidir. YAGNI (You Aren't Gonna Need It) — ihtiyaç duyulmayabilecek bir şey için kod yazmayın. Bu ilkeler, gereksiz tekrar olmadan temiz, bakımı kolay kod yazmaya yardımcı olur.

Android Platform Desenleri

ViewModel (Android), UI durumunu depolamak için Jetpack mimari bileşenidir, ekran döndürmeye karşı dayanıklıdır. ViewModel, Activity'ye referans içermez ve otomatik olarak temizlenir. LiveData — yaşam döngüsü bilincine sahip gözlemlenebilir veri kabı. StateFlow — Kotlin Flow tabanlı LiveData'nın modern bir yedeği. SharedFlow — tek seferlik olaylar (gezinme, bildirimler) için Hot Flow.

Data Binding ve Two-Way Binding — Android'de UI ve verileri bağlama mekanizmaları. Data Binding, XML'de bağlantıyı bildirir; Two-Way Binding, ViewModel'deki alanı otomatik olarak günceller. Unidirectional Data Flow — verilerin tek yönde aktığı ilke: State → UI → Event → State. IT Sectr'de tüm yeni projelerde Unidirectional Data Flow kullanıyoruz — beklenmedik durum değişikliklerinden kaynaklanan hata sayısını azaltır.