Bridge 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; soyutlamalar ve gerçekleştirmeleri arasındaki bağımlılığın gelişimi kısıtlaması problemidir. Bu yazımızda, bu problemi çözmek için kullanabileceğimiz Bridge Design Pattern yapısını inceleyeceğiz.
Konuya başlamadan önce problemin ne olduğunu biraz analiz edelim;
Tüm bankalardaki hesaplarımıza ait işlemleri tek merkezden gerçekleştirebileceğimiz bir uygulama geliştirdiğimizi varsayalım. A,B,C gibi bankalarda bulunan Eur, Usd gibi hesaplarımız ve bu hesaplar üzerinde para çekme/yatırma gibi işlevlerimiz olsun. Uygulamanın aşağıdaki kuralları izlediğini kabul edelim :
1- Her bankada para yatırma ve çekme işlemleri için farklı kurallar bulunabilir. Örneğin A bankasındaki dolar yatırma işlemleri 5 farklı kuralın kontrolünden geçtikten sonra gerçekleştirilebiliyor iken B bankasındaki dolar yatırma işlemleri 3 farklı kurala göre gerçekleştirilebiliyor olsun.
2- Bankalardaki para yatırma ve çekme işlemleri birbirlerinden farklı kuralları kontrol ediyor olabilir. Örneğin A bankasındaki dolar yatırma işlemi 2 farklı kuralı kontrol ederken euro yatırma işleminde yalnızca hesabın aktif olup olmadığı kontrol edilebiliyor olsun.
Problemin çözümü için MoneyAccount arayüzünü implement eden UsdAccount, EurAccount gibi sınıflar oluşturabilir. Ayrıca, her bir banka sınıfı alt sınıf olarak tanımlanıp UsdAccountBankA, EurAccountBankB gibi sınıflar oluşturulabilir. Bu durumda aşağıdaki gibi bir yapı elde edilecektir :
Yukarıdaki yapıda soyutlama ve gerçekleştirme arasında yüksek bir bağımlılık söz konusudur. Para birimlerindeki bir değişiklik bankaları da etkileyecektir. Yeni bir para biriminin sisteme eklenmesi ile birlikte banka sayısı kadar alt sınıf sisteme eklenmelidir. İlerleyen süreçte, para birimi sayısının ve banka sayısının artması ile birlikte çok fazla sayıda alt sınıf oluşacaktır. Ayrıca bankalardaki hesap sınıfları da para birimine bağımlı olacaktır.
Bridge Design Pattern, soyutlamalar ve gerçekleştirmeleri arasındaki bağımlılığın minimuma indirilmesi amacı ile kullanılır. Temel olarak soyutlama ve gerçekleştirim arasındaki ilişkinin “is a” ilişkisinden “has a” ilişkisine dönüştürülmesine dayalıdır. Yapısal(Structural) tasarım desenlerinden biridir ve kullanılması ile yapısal olarak daha karmaşık gözükse de çok daha esnek ve geliştirilebilir bir yazılıma ulaşılması gibi avantajlar elde edilir.
Öncelikle çözümümüzü yazılıma aktarmak adına örnek bir yapı oluşturalım :
Görüldüğü gibi MoneyAccount Interface’ini implement eden MoneyAccountAbstraction isimli bir soyut sınıf bulunmaktadır. Hesabın ilk aktivasyonu ve ilk aktivasyonda default olarak bakiyenin 0 olarak atanması işlemi bu sınıfta gerçekleştirilir. Bu soyut sınıftan ise UsdAccount ve EuroAccount sınıfları türetilmiştir. Bankalardaki para işlemleri için tasarıma devam edecek olursak :
Yukarıdaki gibi, Bank isimli soyut sınıftan banka sınıfları türetilmiştir. Bu tasarımdaki asıl olay, bu soyut sınıfın sahip olduğu MoneyAccountAbstraction tipindeki nesnedir. Soyut sınıfın, ilgili sınıftan türetilmesi yerine ilgili sınıfın nesnesine sahip olması ile birlikte “is-a” ilişkisi “has-a” ilişkisine dönüştürülmüştür.
Artık para yatırma işlemlerini gerçekleştirebilecek bankaları yapıya ekleyebiliriz :
Para birimleri üzerindeki işlemleri birbirinden farklı olarak gerçekleştirebilecek banka sınıfları yazılıma eklendi. Ayrıca her banka, para birimleri için işlemleri ayrı ayrı gerçekleştirebiliyor. Uygulamada istenilen kurallar artık sağlandı.
İstemci tarafında işlemlerin nasıl gerçekleştirildiğini inceleyecek olursak;
Output :
Toplam Bakiye : 250.0
Toplam Bakiye : 480.0
TÜM YAPI
Bridge Design Pattern konusunun ayrıntılarını ve inceliklerini öğrendiğimize göre tüm yapıyı incelemeye başlayabiliriz :
Output :
Toplam Bakiye : 250.0
Toplam Bakiye : 480.0
Bir sonraki yazıya göz atmak isteyebilirsiniz :
