Android Projelerimizde neden Use Case sınıflarını kullanmalıyız?
Herkese merhaba,
Android projesi geliştirmek isteyenler için birden fazla proje mimarisi seçeneği bulunmaktadır. Clean Architecture da bunlardan biridir. Bildiğiniz üzere Clean Architecture ile bir proje tasarlanmak istendiğinde, ilgili projenin bazı mimari prensiplerini sağlaması beklenir. Bahsedilen bu prensiplerden bir tanesi projenizin iş mantığını Use Case sınıflarına taşımaktır. Peki bu Use Case sınıfları nedir, ne işe yararlar ve neden bu sınıfları projemizde kullanmalıyız?
Giriş
Bu makalede, önce Use Case’i kavramsal olarak inceleyip Android projelerinde ne amaçla kulllanıldığından bahsedeceğiz. Daha sonrasında Use Case sınıflarının Clean Architecture yapısında hangi katmana eklenmesi gerektiğini göstereceğiz. Son olarak da Use Case’in bize sağladığı avantajlardan bahsedip neden projelerimizde Use Case i kullanmamız gerektiğini göreceğiz.
Use Case nedir?
Yazılım ve Sistem mühendisliğinde, bir Use Case, bir rol (Birleşik Modelleme Dili’nde bir aktör olarak bilinir) ile bir hedefe ulaşmak için bir sistem arasındaki etkileşimleri tipik olarak tanımlayan eylemlerin veya olay adımlarının bir listesidir. Clean Architecture’da , bu Use Caseler, varlıklara ve varlıklardan yapılan veri akışını düzenler ve bu varlıkları, kullanım senaryosunun hedeflerine ulaşmak için Kritik İş Kurallarını (Critical Business Rules) kullanmaya yönlendirir. Clean Architecture’da tüm uygulamaya özel iş kurallarının Use Case çemberine girdiğini söyleyebiliriz.
Diğer bir değişle Use Case uygulamamızın bir özelliğidir. Peki “özellik” nedir? Sadece bir yolla ilişkili olan ekranlar kümesine özellik denir. Mesela, Profile ve AddedProfile ekranlarımız var ve bu iki ekran ortak bir özelliği kullanıyor (Örneğin, getUserData, updateUserProfilePicture, vb.). İşte bu ortak özelliklerin tamamına Use Case diyoruz. Yani Use Caseler, tek bir özellik içinde yapabileceğimiz tek eylemlerdir.
Clean Architecture’da Use Case Yerleşimi
Clean Architecture’da projeyi 3 katmana ayırırız. Bu katmanları Presentation, Domain ve Data katmanları olarak adlandırabiliriz. Use Case bu katmanlardan Domain katmanında yer alır.
•Presentation (UI için): Tüm şekillendirilebilir yapılarımızı bu katmana ekleriz. View ve View Modeller de bu katmana dahildir.
•Domain: Modellerimizi (veri içeren entityleri) ve Repository arayüzleri bu katmana dahildir. Aynı zamanda Use caselerle birlite projenin iş mantığı da bu katmanda tutulur.
•Data: Adından da anlaşılacağı gibi verilerimizi içerir. API arayüzleri, veritabanı ve Repository Implementation bu katmanda bulunur.
MVVM’deki Yapılarla Clean Architecture Use Case Yapısının Karşılaştırması
Temel olarak MVVM (Model-View-ViewModel), Android Projelerinde design pattern olarak tercih edilir.
Clean Architecture da bu yapının biraz daha genişletilmiş ve geliştirilmiş versiyonu diyebiliriz.
- MVVM’de Model, View ve ViewModel modülleri vardır. Clean Architecture’da ise bu modüllere bir de Use Case katmanı eklenmiş ve bu katman bütün projenin iş mantığını tutan katman olarak belirlenmiştir.
- MVVM’de iş mantığı ViewModels’e yerleştirilir ve proje büyüdükçe , ViewModel bir süre sonra her şeyi yapmaya başlar. Bildiğiniz üzere Clean Architecture prensiplerinden biri de tek sorumluluk (Single Responsibility) mantığıdır. MVVM’ de oluşan bu bütün işin ViewModel’e yüklenmesi olayını Clean Architecture’da Use Case kullanarak çözmüş oluyoruz.
Use Case Kullanmanın Avantajları
- Çoğu kez tekrar kullanılabilirler.
Örneğin, GetUserProfile için oluşturduğumuz bir Use Case’i Profille ilgili bütün ekranlarda kullanabiliriz.
2. Use Caseler kod tekrarını ortadan kaldırır.
Örneğin, eğer Use Caseler olmasaydı ve bütün iş mantığını Viewmodel’in içine koysaydık ve aynı verilere erişmesi gereken 2 View Modelimiz olsaydı, iki view modelde de aynı koda sahip olurduk. Diğer yandan, Use Casemiz varsa ve bahsettiğimiz kodu Use Case’e koyarsak her iki ViewModelde de bu Use Case sınıfını çağırarak, kullanabiliriz.
3. Screaming Architecture’a öncülük eder.
Bu durum, Use Case sınıflarına baktığımızda içinde projeye ait “özellik” paketlerimiz olduğu için, projenin gerçekte neyle ilgili olduğunu anlayabileceğimiz anlamına geliyor. Mesela Profil ekranı için oluşturduğumuz Use Caseleri inceleyecek olursak, Profil ekranında kullanıcının neleri yapıp yapamayacağı hakkında bilgi sahibi oluruz.
4. View Model’i Basitleştirir
Use Case işi yapar, ViewModel ise , Use Case tarafından döndürülen bilgilere göre LiveData’yı günceller. Böylece ViewModel’in artık daha az iş yükü olur yani View Model basitleşir.
5. Projenin View Model’e olan bağımlılığını azaltır.
Use Caseler, Repositorylere erişir, ViewModel ise yalnızca Use Case’e erişebilir. Yani, Use Case kullandığımızda ViewModel’in Repository’ye doğrudan erişimi yoktur.
Use Case sayesinde ViewModel ile Repository arasına yeni bir katman eklenmiş olur ve bu durum da projede ViewModel’e olan bağımlılığı azaltır.
Not
Her Repository için yeni bir Use Case örneği eklenir. (Bazı istisnalar vardır)
Aynı zamanda bir Use Case’in içinde, başka Use Caseler tanımlanabilir ve kullanılabilir.
Özet
- Use Caseler kullanıcının yaptığı işlerin tanımlandığı yani bütün iş mantığını taşıyan paketlerdir.
- Use Case Clean Architecture prensiplerini gerçeklemede büyük rol oynar.
- Use Case bir Clean Architecture yapısında Domain katmanına eklenir.
- Use Case kullanılan bir Clean Architecture projesinin, MVVM ile oluşturulmuş bir projeye göre bir çok avantajı vardır.
- Use Caseler tekrar tekrar kullanılabildikleri ve bu sayede kod tekrarını ortadan kaldırdıkları için ve aynı zamanda ViewModel’i basitleştirip ViewModel ile Repository arasında köprü oluşturarak projenin View Model’a olan bağlılığını azalttığından Android projelerinde kullanılması gereken bir yapıdır.
