Yazılım Tasarım Desenleri – Tasarım Kalıpları Nelerdir?

Yazılım Tasarım Desenleri Nedir? Neden Kullanılır?

Yazılım tasarım kalıpları genellikle yazılım projelerinde sıklıkla karşılaşılan sorunları çözmeye yönelik ortaya atılmış tasarım ve şablonlar olarak tanımlanabilir. Var olan tüm tasarım desenleri, tasarım prensipleri ele alınarak ortaya konmuştur. Yazılımcıların yıllar süren tecrübeleri sonucunda iyi bir yazılım ortaya koyma amacıyla, tekrar eden problemlere karşı, tekrar tekrar kullanılabilir bu çözümlere yazılım tasarım desenleri denir.

Ortaya konulan yazılım tasarım desenleri programlama dilleri veya geliştirme ortamlarından bağımsızdırlar. Diller ve ortamlar değişse de yazılım tasarım kalıpları sunduğu çözümler ile geçerliliğini korumaya devam eder. Temel amaçlarından birisi yazılım geliştirme süreçlerini basitleştirmektir.

Yazılım tasarım desenleri, kodun okunabilirliğini arttırırlar ve bu desenlerin yazım şekilleri standartlaşmıştır. Desenler kullanıldığı projelere katılan yeni yazılımcıların da adaptasyonunu kolaylaştırır. Projeye uygulama aşaması zahmetli ve zor olsa da ilerleyen süreçler için yeni geliştirme ve bakım maliyetlerini düşürür. Bu yazımızda sektörde sıklıkla kullanılan birtakım yazılım tasarım desenlerinden bahsedeceğiz. Bunları ise Oluşturucu Tasarım Desenleri ve Yapısal Tasarım Desenleri olarak iki ana gruba ayıracağız.

Oluşturucu Tasarım Desenleri – Creational Design Pattern

Birçok tasarım desenini bir grupta toplayan oluşturucu tasarım desenleri, sınıfların nasıl yaratılması gerektiği hakkında bazı tavsiyeler sunar. Bu yazılım kalıplarının arka planında yatan ana düşünce bir yazılımın nesnelerinin ne şekilde yaratıldığından etkilenmemesi ve projede yapılacak değişikliklerin kolayca uygulanabilmesi gerektiğidir.

Singleton Desing Pattern – Singleton Tasarım Deseni

Singleton adından da çıkarımda bulunulabileceği gibi bir sınıfa ait tek bir nesne yaratmak amacıyla kullanılır ve bu desen kullanıldığında 2. bir nesne yaratılamaz. Bu tasarım kalıbının amacı oluşturduğumuz nesneye global erişim sağlamaktır ve nesne statik olarak oluşturulur, new operatörü kullanılamaz. Çok istemcili sistemlerde hataların önüne geçmek için oluşturmak istediğimiz objeyi kilitlememiz gerekmektedir.

Singeton Desing Pattern Ne Zaman Kullanılır?

Her istekte yeniden açılan ve yüksek miktarda sistem kaynağı harcayan sınıflarda, tekrar tekrar nesneler oluşturmanın önüne geçmek istediğimizde kullanılır. Bunu yerine tek bir nesneden oluşan bağlantıları kontrol etme yoluna gideriz. İş katmanında çeşitli metodları yerine getiren manager sınıfından her istemci için yeni bir nesne oluşturmak yerine sadece tek bir nesne oluşturarak tüm istemcilere hizmet sunması sağlanır.

Singeton Desing Pattern Kullanılmaması Gereken Durumlar

Eğer bu tasarım kalıbıyla bir nesne yaratırsak, nesneyi kapatmadığımız sürece bellekte yer tutacaktır. Ortak bir şekilde yoğun bir kullanım amacı bulunmuyorsa ve sistemdeki istemciler genellikle birbirinden bağımsız işlemler yapıyorsa bu tasarım deseni kullanılmamalıdır.

Factory Desing Pattern – Fabrika Tasarım Deseni

Yazılım tasarım desenleri arasında en önemlilerden biri fabrika tasarım desenidir. İsmini günlük hayatta karmaşık nesneleri üretmeye yarayan fabrikalardan almıştır. Nesne yönelimli programlamada da bu tarz karmaşık bir yapı bulunmaktadır ve bazı nesnelerin kullanıcı tarafından erişilebilen başlangıç fonksiyonları yoktur. Client nesnesi doğrudan erişemediği bu nesneleri bir fabrika nesnesi yardımıyla üretir.

Bu sayede client nesne yaratma işlemlerinin karmaşık yapısından tamamen soyutlanmış olur. Tüm işi onun yerine fabrika nesnesi yerine getirir ve bu sayede client kendi işine odaklanmış olur.

Fabrika tasarım deseni sayesinde kodun okunabilirliği yükselir ve kullanılabilirlik fazlasıyla artar. Buna ek olarak projenin geliştirme ve yenileme çalışmalarının çok daha kolay yapılmasını sağlar.

Yazılımcıyı çalıştığı sektöre göre özel uzmanlık gerektiren durumlardan kurtarmış olur. Bu sayede bir yazılımca örneğin bir bankacılık sistemi hakkında çok detaylı bilgi sahibi olmadan da proje geliştirebilir. Aynı şekilde projenin diğer ucunda bankacılık hakkında detaylı bilgi sahibi olan uzmanların da istemci tarafında detaylı bilgi sahibi olması gerekliliği de ortadan kalkmış olur.

Abstract Factory Desing Pattern – Soyut Fabrika Tasarım Deseni

Soyut fabrika tasarım deseni aynı fabrika tasarım deseni gibi nesneler oluşturmaya yarar. Fakat bu tasarım kalıbında amaç bir nesne yerine nesneler sepeti oluşturmaktır. Farklı özelliklere sahip birden fazla arayüzden değişik kombinasyonlarla nesne üretmeye yarar. Bunun için arayüz içindeki özellikleri alt sınıflarda override yani ezme işlemi yaparız.

Fabrikaların extend edildikleri sınıfların soyut olmasının asıl sebebi farklı ihtiyaçlara göre farklı özelliklerde ürünlere gerek duyulmasıdır. Soyut fabrika tasarım kalıbı kullandığımız yerlerde if-else yada switch bloklarına yer vermeyiz. Bu bakımdan tasarımın tamamen modüler olduğunu söyleyebiliriz.

Yazılım tasarım kalıpları arasında birden fazla fabrika desenini tek bir arayüzde toplaması sebebiyle fabrikaların fabrikası olarak da isimlendirilir.

Abstract Factory, Concrete Factory, Abstract Product ve Concrete Product modüllerine sahiptir.

Abstract factory modülü factory sınıflarımız için bir arayüz sunarken, concrete factory modülü ürün ailesi oluşturucu sınıflarıdır. Abstract Product ise belli başlı ürünlerin tek bir yerde toplanabilmesi için arayüz sunar. Concrete Product ise istemci tarafından doğrudan kullanılan gerçek sınıflardır.

Abstract Factory Tasarım Deseni Ne Zaman Kullanılır?

Eğer fabrika deseninde if-else gibi bloklar kullanmak istemiyorsak veya birden fazla ürün ailesiyle çalıştığımız bir proje yürütüyorsak soyut fabrika deseni kullanmak mantıklıdır.

Bu sayede istemciye herhangi bir karar mekanizması sunmadan, geliştirmeye ve yeniliklere oldukça açık bir tasarım yapısı kurmamızı sağlar. Herhangi bir ürün eklemek istediğimizde sistemin genel iskeleti üzerinde bir değişikliğe gitmeden değişiklikleri arayüzler üzerinde kolayca halletmemizi sağlar.

Yeni nesne oluşturmayı çok kolaylaştırır ve değişiklikler için üst kısımlarda kod düzeltmelerine sebep olmaz.

Builder Desing Pattern – Builder Tasarım Deseni

Builder tasarım deseni bir ürünü parça parça birleştirerek compozit bir nesne ortaya çıkarmaya benzetilebilir. Örneğin bir araba üretim bandında farklı farklı parçalar üretilir ve belirli bir sırayla birleştirilerek ortaya kapsamlı bir nesne çıkar. Bu yazılım tasarım kalıbı birden fazla alt nesneye sahiptir ve bu nesnelerin sıralanışı bazı durumlarda çok önemli olabilir. Sıra faktörü diğer desenlerden belirgin bir şekilde ayrılmasına neden olur.

Builder tasarım desenine gerçek hayattan bir örnek vermek gerekirse hamburger yapılış adımlarını ele alabiliriz. Bu desende de aynı buna benzer şekilde farklı alt nesnelerden farklı özelliklere sahip daha büyük nesneler inşa edilir. Bu inşa sırasında hangi adımın ne zaman yapılacağının sıralamasını ister director, istersek de abstract kısmında yapabiliriz.

Client, builder, concrete builder ve product sınıf yapıları vardır. Bu desende compozit nesne oluşumuna odaklanırız ve bu sayede arkadaki çeşitli işlemlerden soyutlanmış oluruz.

Eğer projede çok fazla yeni nesne üretiliyorsa, diğer bir değişle kodlar arasında çok fazla new operatörü kullanılıyorsa bu tasarım desenine yönelmemiz mantıklı olacaktır.

Factory – Abstract Factory ve Builder Tasarım Desenleri Karşılaştırması

  • Hepsi oluşturucu tasarım deseni olduğu için nesne oluşturma görevleri birbirine benzer.
  • Factory tasarım deseninde kompozit bir nesne üretme amacı yoktur sadece tek bir nesne üretilir. Eğer alt sınıfları olmayan, tek bir metod ile oluşturabileceğimiz bir nesne üzerinde çalışıyorsak bu desene yöneliriz.
  • Abstarct factory tasarım deseninde de kompozit nesne oluşturma amacı yoktur. Factory gibi nesne üretir ama bu kez içinde bir sürü nesne barındıran bir nesneler sepeti üretmek amaçlanır.
  • Builder deseni ise parça parça alt nesneler üreterek bunları kompozit bir hale getirerek, daha büyük bir nesne elde etmeyi amaçlar. Bu amacına ilerlerken sıralama oldukça önemlidir.

Prototype Desing Pattern – Prototip Tasarım Deseni

Bu tasarım deseninde amaç elimizdeki bir nesneyi tüm özellikleri ile kopyalamaktır. Prototip tasarım deseni ile bellekte aynı türden iki farklı nesne tutulur fakat bu nesnelerin adresleri aynı değildir. Bu sayede kopya içerikte yapılan değişiklikler orijinal nesnemizi etkilemez.

Bu tasarım kalıbı deep copy isminde bir kopyalama yöntemini kullanmaktadır. Eğer nesneyi kopyalarken KopyalanacakNesne=Orijinal nesne gibi bir tanımlama yaparsak yanlış olur. Bu durumda sadece nesnelerin adreslerini eşitlemiş oluruz(buna shallow copy denir) çünkü programlama dillerinde sınıflarımız referans tipleridir.

Prototip tasarım kalıbı Prototype, Concrete Classs ve Client isimlerinde sınıf yapılarına sahiptir.

Eğer bir nesneyi tam manasıyla kopyalamak istiyorsak serialize ederek(saklanacak forma dönüştürmek) bir veri kaynağına yazma yoluna gideriz. Bu serialize işleminin nedeni sisteme gönderilen taşıma isteğidir. Daha sonra elde edilen veri deserialize edilerek nesne modeline dönüştürülür ve yeni nesne oluşturma tamamlanmış olur.

 

YAPISAL TASARIM DESENLERİ – STRUCTURAL PATTERNS

Yazımızın bu kısmına kadar nesne yaratmaya yoğunlaşan oluşturucu tasarım desenlerinden bahsettik. Tasarım kalıplarının ikinci grubunu ise yapısal tasarım desenleri oluşturur. Bu desenlerin amacı nesneler arasındaki bağlantıyı geliştirmek ve daha kullanılabilir hale getirmektir. Aynı zamanda bileşenlerin ve modüllerin ne şekilde davranacağını ve verinin nasıl bir yol izleyeceğini açıklar.

Facade Desing Pattern – Facade Tasarım Deseni

Facede cephe, önyüz gibi bir anlamı karşılamaktadır. Facade tasarım kalıbı ile alt sistemleri direkt olarak kullanmayız. Bunlar yerine alt sistemlere önyüz denilen yapılarla erişiriz. Arayüz görevi gören bu yapılara facade sınıfları ismi verilir. Client sınıflarının isteklerine erişmesini sağlayan facade sınıflarında yapılmak istenen işlemlerin hangi sırayla yapılacağı da belirlenebilir.

Facade Tasarım Deseni Ne Zaman Kullanılır?

  • Eğer projemiz küçük ve kompleks parçalardan oluşuyorsa bu tasarım desenini kullanabiliriz.
  • Client sınıfımız sadece facade sınıfını bildiği için kodun daha kolay anlaşılmasını ve sade bir kod yapısını mümkün kılar.
  • Projemizde nesne ilişkileri ve sınıf sayısı çok fazlaysa kullanılması büyük işlevsellik sağlar.
  • Sık görülen değişikliklerin sistemin iskeletinde değil de alt sınıflarda görüldüğü durumlarda bu tasarım desenini kullanmak mantıklıdır.

Adapter Desing Pattern – Adapter Tasarım Deseni

Adapter tasarım deseni yazılımcıya yeni özellik ve bileşenleri kolayca adapte etme imkanı sağlar. Bu tasarım desenini kullanmak için yeni bir adapter sınfı tanımlanır ve bu sınıf entegre edilmek istenen sınıfa referans barındırır.

Adapter tasarım deseninin uygulanabilmesi için hedef sistemin iyi bir tasarıma sahip olması gerekmektedir. Hedef sınıfı, adapter, adaptee ve client şeklinde sınıf yapıları bulunur.

Proxy Desing Pattern – Proxy Tasarım Deseni

Tasarım kalıpları arasında dikkat çeken bir diğer kalıp proxy tasarım desenidir. Veri aktarımı çok uzun sürüyorsa, bu tasarım deseniyle aldığımız veriyi cache içinde tutup sonra client sınıfına verebiliriz. Buna önbellekleme işlemi denir ve her seferinde veriyi veri kaynağından almak yerine veriyi kullanıma hazır olarak saklar. Belli aralıklarla saklanan veri kontrol edilir ve verideki değişiklikler güncellenir.

Proxy tasarım deseni Client, Soyut Sınıf, Real Concrete Sınıf ve Proxy Sınıf yapılarından meydana gelir. Bu tasarımı sunucularda sıklıkla görürüz. Örneğin sunucuda bir hata yada gecikme meydana geldiğinde, veriler Proxy nesnesi sayesinde önbellekten getirilir ve sunucu tekrar kullanılabilir duruma gelene kadar bu şekilde hizmet vermeye devam eder.

Bridge Desing Pattern – Köprü Tasarım Deseni

Bridge tasarım deseni, yazılım projelerinde bize süper bir modülerlik katar. Değişiklikleri köprü nesnesi sayesinde runtime yani çalışma anında yapabiliriz. Bu desen sayesinde implementasyonları abstractlardan ayırmış oluruz. Implementation, Bridge ve Abstraction sınıf yapılarına sahip bu desende Implementation esas işlevlerin yapıldığı yer, Abstraction soyutlama işini yapan yapıdır. Tam aralarında yer alan Bridge ise bu iki yapıyı birbirine bağlayarak köprü görevi görür. Bu ayrılma durumuna decouple denir. Eğer proje içinde bu iki adımı birbirinden bağımsız olarak sık sık değiştiriyorsak; bu işlemlerin daha kolay ve gelişime açık bir şekilde yürütülmesi için bu tasarım prensibinden faydalanabiliriz.

Bu desende kullanılan tüm sınıf yapılarını Client, Abstraction, Defined Abstraction, Implemantation ve Concrete Implemantation olarak belirtebiliriz.

 

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir