Template 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; bir algoritmanın mutlaka belirli adımları uygulaması, bununla beraber bazı adımlarının değiştirilebilir bazı adımlarının ise değiştirilemez olması ihtiyacıdır. Bu yazımızda, bu problemi çözmek için kullanabileceğimiz Template Design Pattern yapısını inceleyeceğiz.
Konuya başlamadan önce problemin ne olduğunu biraz analiz edelim :
Bir sosyal medya uygulamasına login olma adımlarını göz önüne alalım.
1- Kullanıcıya ait eşsiz bir bilgi girilmesi istenir.
2- Kullanıcının parolası istenir.
3- Kullanıcı bilgisi ve parola eşleşmiyor ise hata ile ilgili ekrana mesaj bastırılır ve ilk adıma geri dönülür.
4- Kullanıcı bilgisi ve parola eşleşiyor ise hesaba giriş yapılır.
Yukarıdaki 4 adım tüm sosyal medya girişlerinde ortak olan adımlardır. Dolayısı ile herhangi bir sosyal medya uygulamasına giriş yapılabilmesi için tüm adımların başarılı bir şekilde tamamlanması gerekmektedir. Bununla beraber, uygulamaya göre farklılık gösteren adımlar veya farklılık gösteremeyecek adımlar olabilir. Örneğin;
1- Kullanıcıya ait eşsiz bilgi A uygulamasında yalnızca “kullanıcı adı” olabilirken B uygulamasında “telefon numarası” veya “mail adresi” olabilir. Uygulamadan uygulamaya farklılık gösterebilen bir maddedir.
2- Kullanıcı parolası mutlaka girilmiş olmalıdır. Uygulamaya göre farklılık gösterebilecek bir madde değildir.
3- Giriş yapılamaması durumunda, kullanıcıya gösterilecek olan mesaj A uygulamasında “Kullanıcı bulunamadı” iken B uygulamasında “Hatalı kullanıcı adı veya parola bilgisi” olabilir. Uygulamadan uygulamaya farklılık gösterebilen bir maddedir.
4- Kullanıcı bilgisi ve parola eşleştiği zaman tüm uygulamalar hesaba giriş yapmalıdır. Uygulamaya göre farklılık gösterebilecek bir madde değildir.
Template Design Pattern, bir algoritmanın tüm adımlarının sırası ile yerine getirildiğinden emin olur. Belirli adımları algoritmayı kullanacak sınıfların tasarımına bırakırken; belirli adımları onlardan gizleyerek gerçekleştirir. Davranışsal(Behavioral) tasarım desenlerinden biridir ve kullanılması ile birlikte kod tekrarının önüne geçilmesi, hata yapma riskinin düşürülmesi gibi avantajlar elde edilir.
Bankaların vermekte olduğu kredilere göre hesaplama yapan bir uygulama geliştirelim. Uygulamada takip edilmesi gereken temel adımlar aşağıdaki gibi olsun;
1- Müşterinin hali hazırda ödemekte olduğu başka bir kredisi varsa yeni kredi çekmesi mümkün değildir.
2- Çekilecek olan kredinin aylık ödemesi müşterinin maaşından daha yüksek ise kredi çekmesi mümkün değildir.
3- Kredi hesaplaması bankadan bankaya göre farklılık gösterebilmektedir.
Problem netleştiğine göre Request sınıfımızı oluşturabiliriz :
Problemi çözecek olan algoritmayı çıkartmaya başlayabiliriz :
Öncelikle, farklı bankalara ait hesaplama sınıflarının türetilebilmesi adına CreditCalculator soyut sınıfını oluşturduk. Temel hesaplama işlemini yapacak olan showCreditInfo() metodunu sınıfa yerleştirdik. Dışarıdan kullanımı için public olarak tanımlanan bu metot, alt sınıfların değişiminden korunmak amacı ile final olarak tanımlanmıştır. Dolayısıyla alt sınıflar tarafından override edilemez ve adımların bütünüyle işlendiğinden emin olunur. Bu sebeple bu metot Template Method olarak adlandırılabilir.
Bununla beraber, canCustomerHaveCredit() , doesCustomerAlreadyHaveAnotherCredit() ve isSalaryEnough() metotları tüm hesaplama sınıflarında ortak işlemleri yapacağından dolayı burada içleri doldurulmuş ve private olarak tanımlanmışlardır. Bu sayede kod tekrarının önüne geçilir ve hesaplama değişikliğine izin verilmemiş olunur.
Ayrıca, getInterestRate() ve calculateCredit() metotları abstract olarak tanımlanmış ve böylece alt sınıfların kendilerine göre işlem yapmalarına izin verilmiştir. Bankalara göre farklı hesaplama işlemleri gerçekleştirilebilecektir.
Artık bu sınıfı extend eden alt sınıfları da tasarıma ekleyebiliriz :
Görüldüğü üzere, her iki bankanın da uygulamakta olduğu faiz oranları farklıdır. Ayrıca, A bankası 100000Tl üzerinde kredi vermemeyi tercih ederken B bankası kredi verirken herhangi bir koşula bakmamaktadır. Bu bankalardan kredi çekmeye çalışacak olursak :
Output :
Hesaplanan Aylık Kredi Ödemesi : 6950,00
Hesaplanan Toplam Kredi Ödemesi : 83400,00
—
Hesaplanan Aylık Kredi Ödemesi : 6260,000000
Hesaplanan Toplam Kredi Ödemesi : 75120,000000
Sonuç olarak bankalara ait kredi hesaplaması yapılırken her iki banka için de aynı adımlar eksiksiz olarak takip edildi. Her iki banka da uyması gereken ortak kurallara uydu, ancak kendilerine ait farklı kuralları da hesaplamada bulundurabildi.
NOT 1: Bir sınıf birden fazla Template Method bulundurabilir ve bu Template Method’lar birbirlerini çağırabilir.
NOT 2: Template Method, özellikle Code Refactoring’te oldukça önemli bir tasarım desenidir. Algoritmalarda kod tekrarının artması durumunda çözüm amaçlı kullanılabilir.
TÜM YAPI :
Template Design Pattern konusunun ayrıntılarını ve inceliklerini öğrendiğimize göre tüm yapıyı incelemeye başlayabiliriz :
Output :
Hesaplanan Aylık Kredi Ödemesi : 6950,00
Hesaplanan Toplam Kredi Ödemesi : 83400,00
—
Hesaplanan Aylık Kredi Ödemesi : 6260,000000
Hesaplanan Toplam Kredi Ödemesi : 75120,000000
Bir sonraki yazıya göz atmak isteyebilirsiniz :
