Açtığım konunun (Yazılım Mimarisi ve Tasarımı - GoF | Factory Method, Singleton ) devamı niteliğinde olan bu konuda Adapter ve Facade anlatacağım.
Adapter ve Facade GoF sistematiğinde Structural (Yapısal) kalıplar kısmında bulunur.
Structural Kalıplar
Yapısal tasarım kalıpları, farklı sınıflar ve nesnelerin daha büyük yapılar oluşturulması için nasıl birleştirileceğine dair taslak sunar. Daha önce açtığım konuda bahsettiğim çoğunlukla aynı temel amaç için farklı yolların kullanıldığı Creational kalıpların aksine, her bir yapısal kalıp farklı bir amaca sahiptir. Yapısal kalıpların tümü nesnelerin arasındaki bağlantıları geliştirir. Yapısal tasarım kalıpları bileşenlerin veya modüllerin yapı içerisinde nasıl düzene gireceklerini açıklar. Ayrıca yapısal tasarım kalıpları kalıp boyunca verinin nasıl hareket edeceğini de açıklar. Sistemin esnek olabilmesi için bileşenkerin nasıl yapılandırılması gerektiğini tanımlarlar.
Adapter
Nesneye yönelik programlamada en büyük avantajlardan bir tanesi de kodun yeniden kullanılabilir olmasıdır. Fakat maalesef biz geliştiriciler geleceği göremiyoruz
Bir projenin gelecekteki kodlama gereksinimlerinin ne olacağını bilmediğimizden dolayı her zaman yeniden kullanılabilir bir sınıfın tasarımının nasıl olması gerektiğini bilemeyiz. Örnek verecek olursak eğer: Diyelim ki geliştirdiğiniz bir uygulama için yabancı bir arkadaşınızdan yardım almak istediniz. Arkadaşınız da benzer bir projede çalışmakta ve size ticari uygulamanın bir bileşeni olan adres sistemini sağlayabilmektedir. Ancak siz arkadaşınızdan dosyları aldığınızda projenizde kullandığınız arayüzler ile dosyadaki arayüzlerin eşleşmediğini fark ettiniz. Daha da kötü bir senaryoda kod İngilizce değil arkadaşınızın kendi dilinde yazılmış. (Ör. Rusça) Bu şekilde bir durumda aklımızda iki tane kötü çözüm canlanabilir.
1- Bileşeni yeniden yazmak
Böylece gereken tüm arayüzleri implente edilmesidir. Bu yöntemin kötü yanı ise arkadaşınızdan her yeni sürüm aldığınızda bileşeni sürekli yeniden yazmak zorunda kalırsınız.
2- Yazdığınız uygulamanızı yeniden yazmak
Uygulamanızı yeniden yazarak arkadaşınızın bileşenlerine uyumlu bir şekilde tekrardan oluşturmak. Buradaki olmusuzluk ise eski arayüzünüzdeki herhangi bir değişiklik esnasında tüm kodu değiştirmek zorunda kalmanız ve kodunuzun anlaşılmasının daha zor olmasıdır. Çünkü siz arkadaşınızın dilini bilmiyorsunuz. Adlandırmalar doğru olsa bile sizin için bir anlam ifade etmeyecektir çünkü arkadışınızın dilini bilmiyorsunuz.
Bu örnekteki problemde ihtiyaç duyulan şey bir tercümandır. İşte tam olarak burda Adapter Tasarım kalıbı devreye girer.
Bu resimde şu anda arkadaşınızın yazdığı kodlar ile sizin sahip olduğunuız kodlar temsil edilmektedir.
Adapter tasarım kalıbı bir güç adaptörüne benzer şekilde davranarak iki tane uyumsuz tipi uyumlu hale dönüştürür.
Adapter tasarım kalıbı: Temelde birbiriyle uyumsuz ancak aynı işi yapması öngörülen iki interface'in haberleşmesi için kullanılır.
Bu tasarım kalıbı sizin uygulamanızın yeni bileşenlerin kullanımına izin verdiği gibi aynı zamanda sizin var olan arayüzlerinizi kullanmaya devam etmenize izin verir. Yeni bir sürüm geldiğinde yapmanız gereken adapteri değiştirmektir.
Sınıf diyagramı:
Framework: Adapter'i kullanan yapı
Adapter: Framework'un kullanılacağı metotları tanımlayan arayüz.
Adaptee: Adapte edilecek tipin metotlarını tanımlayan arayüz. Bu arayüz, çalışma zamanında dinamik olarak belirili Adaptee'nin yüklenmesine izin verir.
Kullancabileceğiniz örnek proje:
.mp3 uzantılı dosyaları çalabilen sırdan bir mp3 çalar programını, .mp4 ve .vlc formatını da çalabilecek bir medya oynatıcısına dönüştürürken kullanabilirsiniz. Yaptığınız diyagramı, yazılım projesini konuya cevap olarak ekleyebilirsiniz.
Facade
Bir sistemi birkaç alt sisteme bölmek size karmaşık sistemlerle başa çıkmanızda yardımcı olur ve çalışmayı parçalamanıza olanak sağlar. Bir sistemi belirli sayıdaki özel sınıflara bölmek, iyi bir nesneye yönelik tasarım pratiğidir. Fakat yine de bir sistemin içerisinde fazla sayıda sınıf bulunması sakıncalıdır. Bu duruma bir örnek olarak bir araba üreticisi düşünelim ve her türlü detayı kullanıcının opsiyonuna bırakmış olsun. Örneğin aracın yakıtı yanarken kullanacağı hava/gaz oranını ayarlanmasını ya da aracın içerisindeki ateşleme sisteminin nasıl işletilmesi gerektiğini sürücünün tercihine bırakıldığını hayal edelim. Bu durumda otomobilin her seferinde ayarlanması gerekir ve bu pekte pratik değildir. Sürücü olarak istenilen tek şey aracın anahtarını takmak ve aracı çalıştırmaktır. Sistemin geriye kalanı sürücünün yerine halledilmelidir. Facade, bu seçenekleri sağlayabilir ve hangi alt sistemin çağırılacağına karar verebilir. Normalde Facade işin çoğunu alt sistemlere atar, fakat birkaç işi kendisi de yapabilmektedir. Facade'in asıl amacı alt sistemlerin saklanması değildir. Amacı bir dizi altsistem için arayüz sağlamaktır.
Örnek:
OtelRezervasyon ve UcusRezervasyon sınıflarını Facade tasarım kalıbını kullanarak sınıfları ayrı ayrı kullanmaya gerek kalmayacak şekilde bir Seyahat sınıfı yaratalım.
Umarım verimli bir konu olmuştur...
Adapter ve Facade GoF sistematiğinde Structural (Yapısal) kalıplar kısmında bulunur.
Structural Kalıplar
Yapısal tasarım kalıpları, farklı sınıflar ve nesnelerin daha büyük yapılar oluşturulması için nasıl birleştirileceğine dair taslak sunar. Daha önce açtığım konuda bahsettiğim çoğunlukla aynı temel amaç için farklı yolların kullanıldığı Creational kalıpların aksine, her bir yapısal kalıp farklı bir amaca sahiptir. Yapısal kalıpların tümü nesnelerin arasındaki bağlantıları geliştirir. Yapısal tasarım kalıpları bileşenlerin veya modüllerin yapı içerisinde nasıl düzene gireceklerini açıklar. Ayrıca yapısal tasarım kalıpları kalıp boyunca verinin nasıl hareket edeceğini de açıklar. Sistemin esnek olabilmesi için bileşenkerin nasıl yapılandırılması gerektiğini tanımlarlar.
Adapter
Nesneye yönelik programlamada en büyük avantajlardan bir tanesi de kodun yeniden kullanılabilir olmasıdır. Fakat maalesef biz geliştiriciler geleceği göremiyoruz
Bir projenin gelecekteki kodlama gereksinimlerinin ne olacağını bilmediğimizden dolayı her zaman yeniden kullanılabilir bir sınıfın tasarımının nasıl olması gerektiğini bilemeyiz. Örnek verecek olursak eğer: Diyelim ki geliştirdiğiniz bir uygulama için yabancı bir arkadaşınızdan yardım almak istediniz. Arkadaşınız da benzer bir projede çalışmakta ve size ticari uygulamanın bir bileşeni olan adres sistemini sağlayabilmektedir. Ancak siz arkadaşınızdan dosyları aldığınızda projenizde kullandığınız arayüzler ile dosyadaki arayüzlerin eşleşmediğini fark ettiniz. Daha da kötü bir senaryoda kod İngilizce değil arkadaşınızın kendi dilinde yazılmış. (Ör. Rusça) Bu şekilde bir durumda aklımızda iki tane kötü çözüm canlanabilir. 1- Bileşeni yeniden yazmak
Böylece gereken tüm arayüzleri implente edilmesidir. Bu yöntemin kötü yanı ise arkadaşınızdan her yeni sürüm aldığınızda bileşeni sürekli yeniden yazmak zorunda kalırsınız.
2- Yazdığınız uygulamanızı yeniden yazmak
Uygulamanızı yeniden yazarak arkadaşınızın bileşenlerine uyumlu bir şekilde tekrardan oluşturmak. Buradaki olmusuzluk ise eski arayüzünüzdeki herhangi bir değişiklik esnasında tüm kodu değiştirmek zorunda kalmanız ve kodunuzun anlaşılmasının daha zor olmasıdır. Çünkü siz arkadaşınızın dilini bilmiyorsunuz. Adlandırmalar doğru olsa bile sizin için bir anlam ifade etmeyecektir çünkü arkadışınızın dilini bilmiyorsunuz.
Bu örnekteki problemde ihtiyaç duyulan şey bir tercümandır. İşte tam olarak burda Adapter Tasarım kalıbı devreye girer.
Bu resimde şu anda arkadaşınızın yazdığı kodlar ile sizin sahip olduğunuız kodlar temsil edilmektedir.
Adapter tasarım kalıbı bir güç adaptörüne benzer şekilde davranarak iki tane uyumsuz tipi uyumlu hale dönüştürür.
Adapter tasarım kalıbı: Temelde birbiriyle uyumsuz ancak aynı işi yapması öngörülen iki interface'in haberleşmesi için kullanılır.
Bu tasarım kalıbı sizin uygulamanızın yeni bileşenlerin kullanımına izin verdiği gibi aynı zamanda sizin var olan arayüzlerinizi kullanmaya devam etmenize izin verir. Yeni bir sürüm geldiğinde yapmanız gereken adapteri değiştirmektir.
Sınıf diyagramı:
Framework: Adapter'i kullanan yapı
Adapter: Framework'un kullanılacağı metotları tanımlayan arayüz.
Adaptee: Adapte edilecek tipin metotlarını tanımlayan arayüz. Bu arayüz, çalışma zamanında dinamik olarak belirili Adaptee'nin yüklenmesine izin verir.
Kullancabileceğiniz örnek proje:
.mp3 uzantılı dosyaları çalabilen sırdan bir mp3 çalar programını, .mp4 ve .vlc formatını da çalabilecek bir medya oynatıcısına dönüştürürken kullanabilirsiniz. Yaptığınız diyagramı, yazılım projesini konuya cevap olarak ekleyebilirsiniz.
Facade
Bir sistemi birkaç alt sisteme bölmek size karmaşık sistemlerle başa çıkmanızda yardımcı olur ve çalışmayı parçalamanıza olanak sağlar. Bir sistemi belirli sayıdaki özel sınıflara bölmek, iyi bir nesneye yönelik tasarım pratiğidir. Fakat yine de bir sistemin içerisinde fazla sayıda sınıf bulunması sakıncalıdır. Bu duruma bir örnek olarak bir araba üreticisi düşünelim ve her türlü detayı kullanıcının opsiyonuna bırakmış olsun. Örneğin aracın yakıtı yanarken kullanacağı hava/gaz oranını ayarlanmasını ya da aracın içerisindeki ateşleme sisteminin nasıl işletilmesi gerektiğini sürücünün tercihine bırakıldığını hayal edelim. Bu durumda otomobilin her seferinde ayarlanması gerekir ve bu pekte pratik değildir. Sürücü olarak istenilen tek şey aracın anahtarını takmak ve aracı çalıştırmaktır. Sistemin geriye kalanı sürücünün yerine halledilmelidir. Facade, bu seçenekleri sağlayabilir ve hangi alt sistemin çağırılacağına karar verebilir. Normalde Facade işin çoğunu alt sistemlere atar, fakat birkaç işi kendisi de yapabilmektedir. Facade'in asıl amacı alt sistemlerin saklanması değildir. Amacı bir dizi altsistem için arayüz sağlamaktır.
Örnek:
OtelRezervasyon ve UcusRezervasyon sınıflarını Facade tasarım kalıbını kullanarak sınıfları ayrı ayrı kullanmaya gerek kalmayacak şekilde bir Seyahat sınıfı yaratalım.
Umarım verimli bir konu olmuştur...
