Builder Tasarım Şablonu (Design Pattern)

Randevusuna yetişmek için apar topar evinden çıkarak metrobüs durağına koştu. Birkaç durak sonrasında inmek için bindiği metrobüste ki yoğunluğu şaşkınlıkla izliyordu. Kapasitesinin üzerinde insan yığmaya ne gerek vardı? Bu insanlar neler hissediyorlar? İnsanların yüzlerinde ki mutsuzluğu bir süre izledikten sonra metrobüsten indi.  Adını ilk defa duyduğu kafeteryaya giderken yine bir kalabalığın ortasında buldu kendini. Birbirlerine çarpanlar, fotoğraf çekilenler, bağrış çağrışın eksik olmadığı yolda gözleri tabelalardan ayrılmıyordu. Sonunda bulduğu kafeteryanın önünde ise kimi dışarıda içeriden yer boşalmasını bekliyor kimi de birini arayan gözlerle içeriyi gözlemliyordu. Aynı bakışlarla içeriyi süzdükten sonra kendisine sallanan eli görmesiyle beraber içeriye adımını attı.

Nazım Hikmet Ran’ın dizelerinin yer aldığı görselle beraber ufak bir hikaye ile giriş yapmış olduk.  Konumuz kalabalık mı gerçekten yoksa tasarım şablonları mı? 🙂 Builder tasarım şablonu sınıflarımızı oluşturmak için kullandığımız parametrelerin karmaşıklığını azaltarak daha sade ve okunabilir düzeyde olmasını sağlar. Aşağıda ki kodları incelediğimizde artan parametreler nedeniyle nesnelerin oluşumu sırasında biz yazılımcılara neyin nereye geldiği konusunda zorluk çıkartmaktadır. Yukarıda ki hikayede bunu açıklar. Kapasitenin üzerinde yolcu alan metrobüs ile kafeteryanın içinde ki arkadaşımızı bulmak için dışarıdan doğru bir süre içeriyi gözlemlememiz karmaşanın olduğu yerde bize bir takım zorlukların çıktığını anlatmaktadır. Artık konumuza teknik düzeyde giriş yapalım.

Bazen sınıflarımızın yapıcı(constructor) metotlarını oluştururken parametre sayısı farklı senaryolar nedeniyle artabilir. Senaryoya göre parametrelere ya null değer veririz ya da senaryoya göre yeni yapıcı metotlar oluştururuz. Mutlu mesut kodumuzu geliştirip devreye alır ve üzerimizde ki sorumluluğunu tamamlamış oluruz. Bir süre sonra yeni bir geliştirme ihtiyacı doğar ve yeni bir parametre daha ekleriz. Yarın bir gün birileri daha gelir yeni parametreler ekler işin içinden çıkamaz kendi ihtiyacına göre constructor oluşturur ve kod alır başını gider. Bu metodu kullanacak yazılımcıların vay haline! Çünkü hangi parametre nerede olacaksa takip edip sırayla parametrelerin değerlerini verir. Hadi bu kötü senaryoyu kodlayalım.

Alışveriş sitesi için telefonlara filtreleme yapılsın isteniyor. İlk ihtiyaca göre brand, model, year ve hasGprs özelliklerine göre filtreleneceği söyleniyor. Hemen kodluyoruz.

Aradan zaman geldi geçti. Telefonlarda gelişmeler oldu ve kamera özelliği geldi. Tabi  o zamanlar selfie yok. Bu geliştirmeyle de artık başka yazılımcı ilgileniyor. Hemen bugün geliştirme yapmamız gerekiyor telefon filtrelerine hasCamera özelliği ekleyeceğiz, denilince oda aşağıda geliştirmeyi yapıyor.

hasCamera nesnesini ekledikten sonra, yeni bir contructor eklemek yerine mevcut geliştirmeye yeni parametre eklemeyi tercih ediyor.Sonra proje birden kırmızıya dönmeye başlıyor. Neler oluyor, yazılımcı şaşkın. Projeye şöyle bir göz atıyor. Mevcut constructor eklenen parametreden dolayı kullanıldığı yerler hata vermiş. Neyse çok büyük problem değil hemen gereksiz yerlerde false değer veririrz yeter diyor. Geliştirmesini tamamlıyor.

Bir süre sonra telefonlara edge internet özelliği geliyor. Yazılımcı hemen bunuda PhoneFİlter sınıfına ekliyor.

Teknoloji durmak bilmiyor 4G teknolojisi ve telefonların işletim sistemleri yaygınlaşıyor. hasGprs ve hasEdge ise artık kullanılmayacağı ve operatingSystem parametresi ekleneceği söyleniyor. Yazılımcı kolları sıvayıp geliştirmesini tamamlıyor ve kodun son hali aşağıda ki gibi oluyor.

Bu geliştirmede yazılımcı eski constructor kaldırmak yerine yeni construcor geliştirip, eski parametrelerin değerlerini mevcut constructor çağırarak veriyor. hasGprs ve hasEdge arıtk kullanılmayacağı için hard-coded olarak false veriyor. Koda baktığıınzda kaldırılmayan parametreler, sıralaması benzer yapıcı metotlar almış başını gidiyor.

Aradan zaman geçiyor ve ekibe yeni yazılımcı kaıtlıyor. Yazılımcı senin gibi bu yazıyı okurken, kendisine yeni bir geliştirme olacağı ve bu işi onun yapması isteniyor. Yazılımcı mutlu ve enerjik başladığı bir günde işi çok güzel anlıyor. Artık 4.5G teknolojisi içinde filtreleme yapılacak. Bunun içinde hasVolte parametresi eklensin isteniyor.

Yazılımcı bir sınıfı inceliyor bir çağırıldığı yeri inceliyor. Sınıfın çağırıldığı kodları bir araya getirip aşağıda ki gibi inceliyor.

İlk üç parametreden sonrasında kafası allak bullak olmaya başlıyor. Sizinde kafanız karışmadı mı? Neyse ki yazılımcıda sizin gibi şanslı ve bu yazıyı okuduğu için refactoring yapmaya karar veriyor ve builder design pattern uygulamaya karar veriyor.

İlk olarak Builder sınıfını konuşalım. PhoneFilter sınıfında yer alan aynı nesneleri ekledik. Hangi nesneye değer verildiğini görmemizi sağlayacak set metotlarını oluşturduk. Ayrıca geri dönüş değerinde ise yine çalıştığımız sınıfın o an ki nesnesini this ile verdik. Yapıcı metodunu oluşturduk. Yapıcı metotda zorunlu parametrelerimizi belirledik. build metodunda ise Builder sınıfının nesnesi üzerinden PhoneFilter metodunun oluşmasını sağladık. PhoneFilter nesnesinin oluşabilmesi içinise PhoneFilter sınıfında Builder sınıfını parametre olarak alan ve değerlerini ilgili nesnelere veren yapıcı metodunu oluşturduk. Artık sınıfımız hazır. Birde test edelim bakalımnasıl görünecek.

Eski PhoneFilter nesnelerimizi yoruma aldıktan sonra her nesneyi Builder statik sınıfı aracılığı ile değerlerini verdik. Görüldüğü üzere iki parametrenin zorunlu olduğu geri kalanlarının ise sadece ihtiyaç duyulanların değerlerinin verildiği bir geliştirme yaptık. Build metodumuzu çağırmamızla beraber artık okunabilir düzeyde nesne oluşturan kodumuz tamamlandı.