Dakikalar İçerisinde Android Clean Architecture
Herkese selam! Bu yazımda sizlere Androidde Clean Architecture mimarisinin nasıl kullanıldığını anlatacağım. Bu yazıdan sonra projelerinizdeki gereksiz bellek kullanımını azaltabilecek ve yazdığınız kodlarda karşılaştığınız hataları daha kolay tespit edebileceksiniz! Hadi başlayalım!
Clean Architecture Nedir?
Clean Architecture yalnızca Android’de değil diğer tüm yazılım dillerinde ve platformlarda kullanılabilen bir yazılım mimarisidir. Bu mimari ile yaptığımız işlemleri katmanlara bölerek kodun daha anlaşılabilir, değiştirilebilir ve sürdürülebilir olması hedeflenir. Ayrıca Clean Architecture ile yazılım geliştirirken uymamız gereken bazı prensipler bulunur. Bunlardan biri de SOLID prensipleridir.
SOLID Prensipleri Nedir?
SOLID prensipleri Uncle Bob olarak da anılan Robert C. Martin’in 2000 yılında Design Principles and Design Patterns adıyla yazdığı makale ile ortaya çıkmıştır. Bu prensipler temelde koddaki karmaşıklığı önlemek üzerine kurulmuştur. SOLID ismi ise 5 temel prensipin baş harflerinin birleşimi ile oluşmuştur. Bunlar;
S-Single Responsibility
O-Open-closed
L-Liskov Substitution
I-Interface Segregation
D-Dependency Inversion.
Single Responsibility
Tek sorumluluk prensipi yazdığımız her bir sınıfın yalnızca bir olayı gerçekleştirmesi gerektiğini esas alır. Yani yazdığımız her bir sınıfın sadece tek bir sorumluluğu olmalıdır.
Open-closed
Yazdığımız kodun değiştirilmeden genişletilebilir olması gerekir. Bu prensipi genellikle interface ve abstract class yapılarını kullanarak gerçekleştiririz. Örneğin bir interface yazarız ve bunun içine bir fonksiyon ekleriz. Daha sonra ise interfaceimizi sınıfımıza uygularız ve daha evvel yazdığımız fonksiyonu sınıfımızın içinde tanımlarız. Bu sayede sınıfımızın yapısını bozmadan yani değiştirmeden yeni bir özelik eklemiş oluruz.
Liskov Substitution
Ana sınıflardan oluşturduğumuz alt sınıfların ana sınıfın sahip olduğu bütün özellikleri olduğu gibi yani herhangi bir koşul durumu eklemeden kullanmasını isteriz. Bunun nedeni ise sınıflarda kullanmayacağımız bir özelliği tanımlamak bellek üzerinde bir yük oluşturur ve uygulamamızın çalışma süresini olumsuz yönde etkiler.
Interface Segregation
Tek bir büyük interface yazmak yerine daha çok sayıda küçük interface yazmayı hedefleriz. Çünkü interface yazdığımız durumlarda bunu bir sınıfa uygularken interface içerisinde yer alan bütün metotları sınıf içerisinde tanımlamamız gerekir ve ihtiyaç duymadığımız metotları sınıf içerinde tanımlarsak zaman ve donanım maliyetimiz artar.
Dependency Inversion
Üst sınıfların alt sınıflara olan bağımlılıklarını yok etmeye çalışırız. Bunun için üst sınıfların soyutlamalara bağımlı olması sağlanır. Yani üst sınıf ile alt sınıfların arasına abstract class ya da interface gibi yapılar eklenir. Bu sayede üst sınıflar direkt olarak alt sınıflara bağımlı olmayacağından kodun esnekliği artırılır bir diğer deyişle bağımlılığı azaltılır.
Solid prensiplerini de öğrendiğimize göre gelin Clean Architecture içerisinde kullandığımız katman yaklaşımına göz atalım.
Clean Architecture Katmanları
Clean Architecture kullanarak yazılım geliştirirken SOLID prensipleri ile kodlarımızı düzenleriz. Ama en az bunun kadar önemli bir diğer husus ise temel katman yapısıdır. Bu yapı sayesinde yazmış olduğumuz kodları doğru bir biçimde paketleyip isimlendirerek kodların ulaşılabilirliğini artırırız. Temel olarak katmanlarımızı 3'e bölebiliriz. Bunlar;
- Data Layer
- Domain Layer
- Presentation Layer.
1-) Data Layer
Data katmanı bizim tüm network ve database işlemlerimizi gerçekleştirdiğimiz katmandır. Bu katman içerisinde kaynak dosyalarımızı oluşturur, uygulamasını yapar ve Repository tasarım kalıbı ile bir üst katman olan domain katmanına iletiriz.
Repository Pattern
Repository tasarım kalıbı bize data katmanında oluşturduğumuz veriye erişirken birden fazla nokta olmaması adına tek bir merkezden erişim yapmamızı sağlar. Bunun yanında bütün verilere tek bir noktada ulaşmanın verdiği avantajla verilerimizi burada test edebiliriz.
2-) Domain Layer
Domain katmanı bizim bütün iş akışımızın sağlandığı katmandır. Data katmanından gelen verileri burada alırız ve çeşitli durumlara göre filtreleyip oluşan çıktıları presentation katmanına göndeririz. Bu sayede presentation katmanında sadece görünüm işlemleri gerçekleştirilebilir. Bu katmanda kullanacağımız yapı ise Use Case.
Use Cases
Use caseler bize yaptığımız işlemleri aksiyonlara göre sınıflandırarak gerçeklememizi sağlar. Aksiyonlara bölerek işlemleri gerçeklediğimiz taktirde gerek olmayan aksiyonlar gerçekleştirilmez böylece zamandan ve donanım maliyetinden tasarruf edilir.
3-) Presentation Layer
Presentation yani sunum katmanında kullanıcının gördüğü arayüz işlemleri gerçekleştirilir. Yani bütün görünümler bu katmanda bulunur. Bu katmanda sadece arayüz gerektiren işlemler yapılmalıdır. Kullanıcıdan girdi almak ya da arayüzü güncellemek örnek olarak verilebilir. Ayrıca görünümlerin yanı sıra her görünüme bir adet ViewModel yapısı eşlik etmelidir.
ViewModel
ViewModel yapısı bizim görünümümüzle domain katmanından gelen verileri birbirine bağlarken kullanılır. Bu yapı sayesinde görünümle veri direkt olarak erişim kurmaz ve bu sayede ortaya çıkabilecek hataların önüne geçilmiş olur.
Artılar-Eksiler
Son olarak bu mimarinin bize kattıklarına ve bizden götürdüklerine gelelim.
Artılar
- Logicleri, uidan uzaklaştırarak yeni özellik eklemeyi kolaylaştırır.
- 3. parti kütüphanelerin birden fazla classla konuşmasını engelleyerek uygulama üzerinde değişiklikler yaparken bize esneklik kazandırır.
- Yaptığımız işlemleri classlara böldüğümüzden daha test edilebilir bir kod yapısı sağlar.
Eksiler
- Küçük çaplı uygulamalarda uygulanmaya çalışıldığında overengineeringe sebebiyet verebilir.
- Uygulamanın yazımında zaman maliyetini artırır.
