Refactoring the Eldest p.2
İlk kısımda bir giriş yapmıştım, şimdi mimari seçtikten sonra gelen yüklerden bahsetmek istiyorum.
Ek kütüphaneler
Android Framework’ün sağladıkları ile projeyi geliştirebiliyor olsaydık ve herhangi bir kütüphaneye bağlılığımız olmasaydı çok güzel olurdu ama sadece mimariyi seçip başlayamıyoruz. Mimari ile birlikte kullandığımız pattern ve layer yapıları için yardımcı olacak kütüphaneler eklememiz gerekiyor.
Bu projenin girdiği güncelleme sonunda elimizdeki ‘tech stack’ Reactive ve DI olsun istiyoruz:
Neleri eklemeliyim diye düşünürken yine “architecture-samples” reposunun en güncellerinden ‘dagger-android’ branchinde şu alanı fark ettim.
ServiceLocator nedir? Obje oluşturma ve kapsamını belirleme görevleri neden bir dependency injection yardımcı framework’ü olan Dagger’a taşınmış?
Service Locator Pattern
Bunun cevabını öğrenmek adına 27 Mart 2010'a gidiyoruz, Microsoft Dependency Injection konusundaki yazısında Service Locator Pattern’i ne için kullanmalısınız şunlarla açıklamış:
- Değiştirilmesi ya da güncellenmesi durumunda olabilecek hiç değişiklik yapmadan ya da olabilecek en az değişikliği yapabilmek adına sınıflarınızın bağlılıklarından ayırmak istiyorsunuz.
- Sınıflarınızı bağlılıkları olmadan izole bir şekilde test etmek istiyorsunuz.
- Sınıflarızın bağlılıklarının yerini tespit etme ve yönetme işlerini sınıfın içinde yapmak istemiyorsunuz.
- Uygulamanızı genel hatlarıyla ayrık geliştirilmiş, test edilmiş, versiyonlanmış ve dağıtılmış modüllerden oluşturmak istiyorsunuz.
Dependency Injection Pattern
Bunu bilmeyeni işe almıyorlar noktasına ulaşmış olan pattern. Ekşi entry’si gibi başladım.
Tanımı en basit halinde bir client-service örneğine indirgersek; client’ın hangi servis objesini kullanacağını belirtmesi yerine DI objesinin client’a hangi servisi kullanacağını söylemesine dayanıyor.
Önemli olan kısım bu iki pattern karşılaştırılacak yaklaşımlar değiller. Android’in minik tanrısı Jake Wharton konuyla ilgili şunu diyor:
Fundamentally a service locator requires you to pull dependencies out of the object that holds them whereas a dependency injector does that on your behalf. You can still perform dependency injection using a service locator
Bu kadar açıklamanın ardından asıl konumuz olan içerisinde ne SL ne de DI barından koca yaşlı şişko projemize dönelim. Bu muazzam migration olayını bir de Kotlin desteği ekleyerek daha da zor hale getirmek gibi bir seçimde bulunduk.
Bunun içinde benim bize en çok yardımcı olabilecek DI kütüphanesini seçmem gerekti; Dagger2 vs Koin vs Kodein
Kodein daha çok genç bu kadar büyük ve karmaşık yapıda bir projeye uygulamak istemem açıkcası. Geriye dagger ve koin kalıyor, onun için de reddit’teki konuyla ilgili tartışma benim için yeterli oldu.
Sonuç olarak şöyle bir proje yapısına karar vermiş bulunuyoruz:
Kotlin, MVVM + Databinding, Dagger, RxJava2, JUnit4 + Mockito (umarım test de yazarız)
Kendime ve takım arkadaşlarıma şans diliyorum. Okuduğunuz için teşekkürler.
