Facade Design Pattern Nedir ?
Design Patterns eğitim serisindeki ilk yazımızda, tasarım desenlerinin “Yazılımcıların sıklıkla karşılaştığı problemlere ve yazılımların doğasında bulunan genel ihtiyaçlara getirilen çözümler” olduğunu söylemiştik. Sık karşılaşılan problemlerden bir tanesi ise; karmaşık alt sistemlerin doğru ve rahat bir şekilde kullanılabilmesi problemidir. Bu yazımızda, bu problemi çözmek için kullanabileceğimiz Facade Design Pattern yapısını inceleyeceğiz.
Konuya başlamadan önce problemin ne olduğunu biraz analiz edelim;
Araba motorunun çalışması sırasında krank mili, piston, triger kayışı vb. pek çok parça birlikte çalışır. İstenilirse bu parçalar ayrı ayrı incelenebilir ancak bizim arabayı çalıştırmak için tek yapmamız gereken şey kontağı çevirmektir. Bunun sebebi, karmaşık pek çok yapının birleştirilerek tek bir harekete bağlı olacak şekilde ayarlanmış olmasıdır. Aynı şekilde bir kütüphanede üyelere ait toplam borç bilgisinin hesaplanması üzerine bir yazılım geliştirdiğimizi düşünelim. Müşterinin tüm borcunu hesaplamak için kitap kiralama, park yeri kullanma, yeme/içme gibi tüm hizmetlere ayrı ayrı ödedikleri ücretlerinin toplaması gerekmektedir. Bu gibi çok sayıda sınıf ve nesne içeren işlemlerin istemci tarafından gerçekleştirilmesi doğru olmayacaktır.
İstemcilerin karmaşık işleri yapmaya çalışması bir takım problemlere sebebiyet verebilir. Elbette ilk aklan gelen problem yanlış hesaplamalardan doğabilecek hatalardır. İstemci tarafında daima arka plandaki işlemleri en ince ayrıntısına kadar bilen birisi bulunmaz. Dolayısıyla, gözden kaçabilecek hesaplamalar olabilir. Proje büyüdükçe ve sınıf, metot sayıları arttıkça bu kaçınılmaz bir hale gelir. Dolayısıyla istemcinin, işlemi en sadece şekilde gerçekleştirebilmesi amaçlanmalıdır. Ayrıca belirli bir yapının oturmamış olması ve işlemlerin yoğun olarak istemciler tarafından gerçekleştirilmesi bakım maliyetini de artıracaktır. Bunlarla birlikte, güvenlik, mahremiyet gibi konular açısından da istemci ile alt sistemler arasındaki bağımlılık minimum düzeyde tutulmaya çalışılır.
Facade Design Pattern, karmaşık alt sistemler ile istemci arasındaki iletişimin doğru ve basit olması amacı ile kullanılır. İstemcinin alt sistemlerin detayları ile ilgilenmesindense mümkünse yalnızca bir veya birkaç arayüz ile iletişim kurmasını hedefler. Bu tasarım deseninde temel mantık, alt sistemlerin birleştirilerek önde duran bir sistem üzerinden kullanılabilmesidir. Yapısal(Structural) tasarım desenlerinden biridir ve kullanılması ile birlikte yazılımlarda test ve bakım maliyetlerinin azaltılması, karmaşıklığın minimuma indirgenmesi ve hata riskinin azaltılması gibi avantajlar elde edilir.
Öncelikle, problemimizi yazılıma aktarmak adına örnek bir yapı oluşturalım :
Görüldüğü gibi, üye nesneleri için LibraryMember ve kitap kiralama işlemlerindeki borçları takip edebilmek için BookDept sınıflarını oluşturduk. Bunlarla beraber, kitap nesneleri için de Book isimli bir sınıf tanımladık. Bu sınıflar içerisinde karmaşık algoritmalar bulunabilmektedir. Belirli kurallara göre belirli hesaplamalar yapılmakta ve buna göre bir ücretlendirme belirlenmektedir.
Borç çıkarımında diğer detayların yazılıma eklenmesi ile sistem daha da karmaşık bir hal alacaktır. Park ücretlendirmeleri, üyelik işlemleri vb. yapıları da yazılıma ekleyelim :
Artık yapıya farklı sınıflar ve bu sınıflar içerisindeki metotlar da eklendi. Bu metotlar kopmpleks, çok parametreli, recursive, override vb. metotlar olabilir. Bu durumda istemcinin doğrudan bu metotların tamamını kullanmaya çalışması hata riskini artıracaktır.
İstemcilerin, karmaşık işlemleri gerçekleştirmesinin önüne geçmek adına bir sınıf tasarlanabilir. Ön cephede durarak istemci ile alt sistemler arasındaki iletişimi sağlayacak olan bu sınıfı tasarlayalım :
Yukarıdaki sınıf, tüm borç hesaplamalarını yapan sınıftır ve bunu ilgili sınıflar sayesinde gerçekleştirir. Elbette, bu sınıfı yazmak nihayetinde kolay değildir ve hesaplama işlemlerini ayrıntılı olarak bilen bir yazılımcı veya ekip tarafından yazılmalıdır. Bu noktada esasen elde ettiğimiz avantajlar aşağıdaki gibi sıralanabilir :
- Bu kompleks yapı yalnızca bir kez oluşturuldu fakat farklı istemciler tarafından defalarca kez kullanılabilir halde olduğundan dolayı kod tekrarı engellendi.
- Kod tekrarı engellendiğinden dolayı olası güncellemelerin tek noktadan gerçekleştirilebilmesi sağlandı. Her bir istemci için ayrı güncelleme yapılmasına gerek kalmadığından dolayı yüksek bakım maliyetinin önüne geçildi.
- İşlemler tek bir merkez üzerinde toplandığından dolayı, her bir istemcinin detaylı olarak nesneler ve metotlar ile uğraşmasına gerek kalmadı. Böylece potansiyel hatalar ile karşılaşma olasılığı düşürüldü.
- İstemcilerin tüm detayları bilmeden gerekli işlemleri gerçekleştirebilmeleri, alt sistemlerin güvenliğinin ve gizliliğinin korunmasını sağladı.
Not : İstemciler istedikleri zaman(aksi için bir tasarım gerçekleştirilmedi ise) alt sistemlere ulaşabilir ve oradaki ayrıntılar ile kendileri uğraşabilir. Dikkatinizi çekeceği üzere, tasarımımızda sınıfların gizlenmesi ve nesnelerin korunması için ekstra önlemler alınmadı. Asıl olarak istemcilerin bu detaylarla uğraşma zorunluluğunu ortadan kaldırmayı amaçladık.
İstemcilerin işlevlerini inceleyecek olursak :
Output :
Toplam borç : 151.23
Öncelikle, bir örnek olması adına LibraryMember sınıfından bir üye nesnesi oluşturuldu ve buna örnek kitaplar atandı. Daha sonrasında, Main içerisinde DeptCalculator sınıfından bir nesne oluşturuldu ve bu nesne üzerinden bir üyeye ait borç hesaplama işlemi gerçekleştirildi. İstemci ve alt sistemler arasındaki iletişimi sağlayan bu nesne, Facade Object olarak adlandırılır.
TÜM YAPI
Facade Design Pattern konusunun ayrıntılarını ve inceliklerini öğrendiğimize göre tüm yapıyı incelemeye başlayabiliriz :
Bir sonraki yazıya göz atmak isteyebilirsiniz :
