Mobil Geliştirmede SoC: Nedir, İlkeleri ve Sorumluluk Ayrımı

SoC Kısaltması Ne Anlama Geliyor

SoC, Separation of Concerns — «sorumluluk ayrımı» veya «ilgi alanlarının ayrılması» anlamına gelir. Geliştirme bağlamında, concern terimi, kullanıcı arayüzü oluşturma, tıklama işleme, veri doğrulama, ağ iletişimi veya veritabanıyla çalışma gibi ayrılabilir herhangi bir işlevselliği belirtir. SoC ilkesi, bir alandaki değişikliklerin diğerlerini etkilememesi için kodun bu alanlar etrafında gruplandırılmasını öngörür.

SoC kısaltması, teknik literatürde, mimari tartışmalarda ve framework dokümantasyonunda yaygın olarak kullanılır. Örneğin, Android Architecture Components dokümantasyonunda, ViewModel ve View'i ayırma motivasyonu olarak SoC defalarca belirtilir. iOS topluluğunda, terim Massive View Controller sorununu tartışırken kullanılır — SoC eksikliğinin doğrudan bir sonucu.

SoC'nin tek seferlik bir eylem değil, sürekli bir süreç olduğunu anlamak önemlidir. Uygulama büyüdükçe yeni sorumluluk alanları ortaya çıkar ve mimarinin yeniden gözden geçirilmesi gerekir. İyi bir kod tabanı, her concern'in izole ve yönetilebilir olduğu istikrarlı bir duruma ulaşmadan önce birkaç ayırma yinelemesinden geçer.

SoC vs Separation of Concerns

Separation of Concerns ve kısaltması SoC aynı ilkeyi belirtir. Tek fark, kullanım bağlamındadır: tam ad, resmi belgelerde, eğitim materyallerinde ve yeni geliştiricilere kavramı ilk kez açıklarken kullanılır. SoC, kısalığın önemli olduğu teknik tartışmalarda, kod incelemelerinde ve dokümantasyonda kullanışlıdır.

Profesyonel bir ortamda, her iki terim de birbirinin yerine kullanılabilir. Bir geliştirici «burada SoC ihlal edildi» veya «bu Separation of Concerns'i ihlal ediyor» diyebilir — anlam değişmez. Ancak, iş ilanlarında ve mimari gereksinimlerinde daha çok tam ad kullanılırken, sohbetlerde ve kod incelemelerinde kısaltma kullanılır. Sektöre rahat bir giriş için her iki varyantı da bilmek gereklidir.

Terminolojik karışıklık vardır: SoC kısaltması, donanım bağlamında System-on-a-Chip (çip üzerinde sistem) için de kullanılır. Mobil geliştirmede, bağlam her zaman ortamdan bellidir — tartışma kod mimarisiyle ilgiliyse, Separation of Concerns'i ifade eder. Bu makalede SoC her zaman sorumluluk ayrımı ilkesini ifade eder.

SoC Mobil Mimaride Nasıl Uygulanır

Üç katmanlı mimari, mobil uygulamalarda SoC'yi uygulamanın en yaygın yoludur. Kodu Presentation (UI), Domain (iş mantığı) ve Data (veri kaynakları) olarak ayırır. Her katman, kesin olarak tanımlanmış sınıf türleri içerir ve arayüzler aracılığıyla komşularından izole edilir. Bu yaklaşım iOS, Android ve Flutter projeleri için eşit derecede etkilidir.

Presentation Katmanı ve ViewModel

View ve ViewModel sunum katmanını oluşturur. View, arayüzü oluşturmaktan ve kullanıcı olaylarını iletmekten sorumludur. ViewModel, ekran durumunu tutar ve Domain katmanındaki verileri görüntülemeye hazır bir biçime dönüştürür. ViewModel, Activity, Fragment veya UIViewController'a referans içermez — bu, UI ve mantık arasında SoC'yi sağlar.

Örneğin, Android Jetpack'te ViewModel, ekran dönüşünden sağ çıkarken UI yeniden oluşturulur. SoC olmasaydı, durum Activity'de kaydedilmek zorunda kalırdı ve yaşam döngüsü yönetimi verilerle karışırdı. ViewModel bu sorunu izole bir şekilde çözerek sorumluluk ayrımı ilkesinin temiz bir uygulamasını gösterir.

Domain Katmanı ve Use Case'ler

Use Case'ler, platformdan bağımsız iş kurallarını içerir. Bu katman, Android SDK, iOS UIKit veya Flutter framework'ünü içe aktarmaz. Bir Use Case, Repository'den veri alır, iş mantığını uygular ve sonucu döndürür. SoC sayesinde, tek bir Use Case farklı ekranlarda ve platformlarda yeniden kullanılabilir.

Klasik bir örnek, kayıt formu için ValidateAndSaveUseCase'dir. E-posta ve şifreyi doğrular, kaydetmek için UserRepository'i çağırır ve bir ValidationResult döndürür. Ne UI ne de veritabanı doğrulama kurallarını bilir — bunlar tek bir yerde toplanmıştır, bu da değiştirilmelerini kolaylaştırır.

Data Katmanı ve Repository

Repository, veri kaynaklarını uygulamanın geri kalanından soyutlar. ViewModel, verilerin REST API, GraphQL, yerel veritabanı veya önbellekten nereden geldiğini bilmez. Repository hangi kaynağın kullanılacağına karar verir ve bu mantığı bir arayüzün arkasına gizler. Bu, veri alma ve veri tüketimi arasındaki SoC'dir.

DataSource daha da derin bir ayırma sağlar: RemoteDataSource yalnızca HTTP isteklerinden sorumludur, LocalDataSource Room, CoreData veya SharedPreferences ile çalışmaktan sorumludur. Repository, önbelleğe alma stratejileri uygulayarak bunları birleştirir. Her DataSource bağımsız olarak değiştirilebilir; bu, sunucular veya veritabanları arasında geçiş yaparken kritiktir.

Bu çok katmanlı DataSource sistemi, altyapı düzeyinde SoC'yi uygular: ağ iletişimi, yerel depolama ve önbelleğe alma, her biri kendi mantığı ve yaşam döngüsüne sahip ayrı concerns'tir. Bir HTTP istemcisi değiştirilirken yalnızca RemoteDataSource değişir, Repository ve üst katmanlar etkilenmez; bu, sorumluluk ayrımının pratik değerini doğrular.

Mimari Desenlerde SoC

MVP (Model-View-Presenter), mobil geliştirmede açıkça SoC'yi uygulayan ilk desenlerden biriydi. Presenter, mantığı içerir ve bir arayüz aracılığıyla View'i kontrol eder. View pasiftir — yalnızca Presenter'ın söylediğini görüntüler. Ayırma, testleri basitleştirir: Presenter öykünücü olmadan test edilir ve View o kadar basit kalır ki kırılacak bir şey yoktur.

MVVM, reaktif bağlama ekledi: View, Observable veya StateFlow aracılığıyla ViewModel'deki değişikliklere abone olur. ViewModel, View'e referans tutmaz, bu da bellek sızıntısı riskini ortadan kaldırır ve concerns'i daha da ayırır. Android'de MVVM, Jetpack ViewModel ve LiveData sayesinde standart haline geldi; iOS'te ise Combine ve RxSwift sayesinde.

Robert Martin'in Clean Architecture'ı SoC'yi halkalar halinde radikal bir ayırmaya götürür. Dış halka (framework'ler ve sürücüler) iç halkaya (varlıklar) bağlıdır, ancak bunun tersi geçerli değildir. Pratikte, mobil projeler nadiren dört halkanın tamamını uygular — Presentation etrafındaki Domain ve Data katmanları yeterlidir. Ancak «içe bağımlılık» ilkesi, framework'leri değiştirirken önemli avantajlar sağlar.

// View — yalnızca görüntüleme, mantık yok
final class LoginViewController: UIViewController {
    let viewModel: LoginViewModel

    func loginTapped() {
        viewModel.login(emailField.text, passwordField.text)
    }
}

// ViewModel — ekran mantığını içerir, UIKit'i bilmez
final class LoginViewModel {
    private let loginUseCase: LoginUseCase

    func login(email: String?, password: String?) {
        loginUseCase.execute(email, password)
    }
}

// Use Case — iş mantığı, platformdan bağımsız
final class LoginUseCase {
    private let repo: AuthRepository

    func execute(email: String?, password: String?) {
        guard let e = email, let p = password else { return }
        repo.authenticate(e, p)
    }
}

Örnek, üç SoC düzeyini gösterir: LoginViewController yalnızca olayları iletir, LoginViewModel durumu yönetir, LoginUseCase iş kurallarını içerir. Her sınıf bağımsız olarak test edilir ve UI framework'ünü değiştirmek Use Case'i etkilemez.

Mobil Projelerde Yaygın SoC İhlalleri

Massive View Controller, iOS'ta en yaygın SoC ihlalidir. UI'yi yöneten, ağ isteklerini işleyen, JSON ayrıştıran ve verileri kalıcı hale getiren bir sınıf, ilkeyi her düzeyde ihlal eder. Çözüm, her sorumluluğu ayrı bir bileşene çıkarmaktır: NetworkingService, JSONParser, CoreDataStack, ViewController'a yalnızca View yönetimini bırakarak.

Android'de benzer bir sorun, God Activity veya God Fragment'tır. Veri yükleyen, formları doğrulayan, iletişim kutuları gösteren ve UI'yi güncelleyen tek bir aktivite. Bu, durum yönetimini ve veriyi üstlenen ViewModel ve Repository'nin eklenmesiyle düzeltilir. ViewModel ayrıca ekran dönüşü sırasında veri kaybını da önler.

Üçüncü ihlal, platform ve iş kodunun karıştırılmasıdır. Örneğin, bir HTTP isteğini doğrudan bir SwiftUI View veya Android Composable içine yerleştirmek. Bu, kodu taşınabilir olmaktan çıkarır ve test etmeyi zorlaştırır. Doğru yaklaşım, isteği bir Use Case aracılığıyla çağrılan bir Repository'ye taşımak ve View'in yalnızca sonuca abone olmasını sağlamaktır. Sistemin her öğesi kendi görevini çözer ve sınırlarının dışına çıkmaz.