Clean Swift Mimarisi-I (Giriş)
Selamlar Arkadaşlar,
Bu yazımda sizlere Ocak 2019'da tanıştığım, o günden bu yana kişisel işlerimde severek kullandığım Clean Swift Mimarisinden bahsedeceğim.
Aslında sadece mimariden bahsetmekle kalmayacağım. SpaceX’in bize sunduğu Public API’yı kullanarak birlikte uygulama geliştireceğiz.
Serinin ana başlıkları aşağıdaki gibi olacak.
Eveeeet başlıyoruz…
Bana göre mimarilerin birbirinden yapı olarak çok üstünlüğü yok. Aslında üstünlük sadece hangi mimarinin daha test edilebilir olduğuyla alakalı. Yani benim ve belki de birçok geliştiricinin gözünde bir mimari test edilmeye ne kadar açıksa o kadar başarılı oluyor. Benim şahsi fikrimde Clean Swift Mimarisi, deneyimlediğim mimariler arasında test edilmesi en kolay mimaridir.
En baştan başlamak gerekirse Uncle Bob’s Clean Architecture esinlenen ilk mimari VIPER idi. Ardından Raymond Law blogunda VIPER mimarisinin temiz mimari ilkelerine tam olarak uymadığı için eleştirdi ve Clean Swift (VIP) mimarisini VIPER’ın iyileştirilmesi olarak önerdi.
Peki VIPER mimarisinde bulunan uyumsuzluk tam olarak nedir? VIP’i VIPER’dan üstün kılan bu temizlik nedir? Bu soruları biraz tartışalım.
VIPER mimari yapısına baktığınızda ana yapılar arasında çift yönlü bir bağlantı olduğunu göreceksiniz. Örneğin Presenter hem ekrana basılacak modeli düzenlerken hemde View tarafından gelen aksiyonları yönlendiriyor. Raymond Law kendince belirlediği temiz mimari kanuna uymadığını söylüyor.
“It may seem convenient for the view controller to ask the presenter directly to format a string. But over time, you’ll end up with a mess in your dependency graph”
Şimdi yukarıdaki resimden VIP yapısına baktığımızda aşağıdaki noktalara dikkat ediyoruz:
- ViewController ile Presenter arasında tek yönlü bir bağlantı var. Görevi sadece View aksiyonlarını işlemek.
- Interactor, ViewController tarafından gelen aksiyonları karşılar. Bunu gerekiyorsa Worker (sunucu isteklerinin gerçekleştirildiği parça) aracılığı ile işler ve ekrana yansıtılması için Presenter’a teslim eder.
Burada en önemli noktalardan biri de aksiyonu gerçekleştirirken sürekli ViewController -> Interactor -> Presenter -> ViewController -> … döngüsünü takip etmesi gerektiğidir. Aslında bu akış döngüsü VIP mimarisinin VIPER mimarisinden daha temiz olmasını sağlamaktadır. Diğer bir deyişle, Presenter kullanıcı arayüzü işlemlerini gerçekleştirmek ve verileri ekrana basmak için hazırlamak yerine sadece verileri ekrana basılacak hale dönüştürür. ViewController artık istekleri ve tüm iş mantığını Interactor’a iletir. Interactor ise gelen isteği işleyerek uygun bir formata dönüştürür (genellikle ViewModels’e), bunu da Presenter’a iletir.
Bu dairesel veri akışının avantajı, her bileşenin artık tek bir iş yapmaya odaklanabilmesidir.
Clean Swift, yukarıda anlattığım konular nedeniyle iOS Geliştiricileri arasında giderek daha popüler hale geliyor. Topluluk tarafından sunulan template sayesinde daha düzenli kod yazmanızı sağlıyor. Bu template mimari bileşenleri arasında gerekli bağlantıları sağlıyor. Sizin yapmanız gereken bölümlere yüklenen görevler kapsamında işlerinizi yapmak oluyor.
Bu hazır yapıyı kullanırken mimarinin bileşenlerini ayrı ayrı oluşturabilmekle birlikte, “Scene” ismi verilen template yapısı ile direkt ekranınıza ait tüm bileşenleri oluşturabiliyorsunuz.
Mimari içinde her bir “Scene” 6 bileşenli bir yapıdadır;
- View Controller
- Interactor
- Presenter
- Worker
- Models
- Router
Ayrıca yine bu kısımda bulunan “Unit Tests” aksiyonu ile test edilebilir (View Controller, Presenter, Interactor, Worker) bileşenlerin otomatik olarak birbirine bağlanmış test sınıflarını oluşturabiliyorsunuz.
Anlatacaklarım şimdilik bu kadar.😊 Clean Swift mimarisine güzel bir giriş yaptığımızı düşünüyorum. Bir sonraki yazıda örnek projemizde kullanmak amacıyla temiz bir network katmanı yazmaya çalışacağız.
Görüşmek üzere 👋
