Data Vinci 5 : Design Patterns

Çalışabilen bir şeyler yazan programcının yeni hedefi. Yeni yazdıklarının daha esnek, bakımı, okunması kolay kodlar yazarak “çalışabilen” bir şeyler ortaya çıkarmak. “Çalışıyorsa kurcalama” tabularını yıkmaktır. Yazılımcılığa ilk başlayan aday, yazdığı destan gibi kodlarla övünür. Abi 10000 satır kod yazdım:) Kişisel bakışı geçelim sektörde bile iş arayan firmalar 10000 satır kod yazmış gibi değişik bir ölçü birimiyle yazılımcı aramış ve belki hâlâ bile arıyordur. Design Patterns kavramını ilk duyduğum an, üniversitenin ilk yıllarında üst sınıflardaki öğrencilerin derste yapmış olduğu “Design Patterns” sunumu idi. Zaman zaman düştüğüm gafletlerden birisine kapılıp  “Bitirme tezi de Photoshop ile mi yapılırmış” gibi bir yorum yapmıştım. Design kelimesinin bana çağrıştırabildiği tek şey, o günlerde Photoshop idi, algım web site “tasarımı”na gitmişti o zamanlar. Sonrasında baya bir süre “Design Patterns” kavramlarını bilmeden mutlu mesut yaşadım. Fularsızlık böyle bir şey işte.

Tabii programlama dilleri gelişti. Farkında bile olmadan kabul görmüş pattern’leri uygulayan kod bloklarını yazdım durdum. Daha sonraki dönemlerde ise İnternet’te rastladığım bu kavrama daha aşina oldum. Fuların bir ucundan yakaladım:)

Design Pattern kavramı GoF(Gang of Four) denilen 4 müstesna şahsın yapmış olduğu bir çalışma ile bilinir. Ancak bu kadar geniş açıdan bakmak aldatıcı olabilir.   Zira bir çok disiplinde “design patterns” kavramı mevcut. Yani olayın özünün nüfuz ettiği alan illa ki java veya c# ile ilgili olmayabilir. Javascript ve Python dillerinin de kullandığı bir takım tasarım desenleri mevcut. Tabii bu dillerin kategorileri “Object Oriented” olmadığı için “Design Patterns” kavramına yaklaşımları da aynı olmayabilir.

Barcelona’nın efsane yıllarından kullandığı pas oyunu “Tiki-taka” mesela bir tasarım deseni olabilir. Hatta Arda’nın (aşçı olan) mutfağında bile uyguladığı belli yöntemler var 🙂 Tüm olay suya makarnayı at, kaynat, süz olsaydı. Makarna yapımı ile ilgili saatlerce program yapılmazdı. Buraya kadar sıkılmadan okumuş, “ben işimi şansa bırakmam” diyenlerle yola devam edelim.

Design Patterns kavramı ( Nesneye dayalı programlama dilleri için) sınıflandırma yapılırken de genelde iki kola ayrıldığı görülür: Creational ve behavioral olmak üzere, ancak burda da yine structural, concurrency gibi daha az duyulan  pattern tipleri yer alıyor.

designpatterns

DoFactory.com ‘dan aldığım ekran görüntüsü üzerinde sıkça adı duyulan (en azından benim için) desenleri sarı ile işaretledim. Her birinin uygulandığı senaryolar farklı. Yine doFactory’de bu desenler için gerçek-dünya senaryoları ve implementasyonları yer alıyor. Göz atmakta fayda var.

Design Patterns kavramı, OOP ( Object Oriented Programming) yazılım geliştirme süreçlerinde göz ardı edilmemesi gereken, fakat bu implementasyonları yaparken de dikkatli olunmasında fayda gördüğüm bir konu. Çünkü aman efendim kodumuz re-usable olsun, sonradan açıp bakan kulaklarımı çınlatmasın kaygısı abartıldığında bu kez bu güzide tasarımlar bağımlılığı ve karmaşıklığı artırıp “Anti-Pattern” buselerine dönüşebilir. Burda aslolan hangi yaklaşımın hangi senaryoda uygun olduğunu tahminlemek. Günümüz “trend” tabiriyle “büyük resimi görebilmek”tir.

Tasarım desenlerinin bir arada kullanılması çok nadir görünen bir durum bir değil, aksine tıpkı astrolojik burçlar gibi, birbirleriyle anlaşan, birbirlerinin yerine konabilen, yahut ateşle barut gibi yanyana duramayan kombinler mevcut. Örneğin Façade adlı tasarım deseni, tek bir instance gerektirdiğinden ötürü “Singleton” pattern’i ile bu gereklilik sağlanabilir. Façade-Singleton.

“I have a façade, i have a singleton. ımmmmm façadesingleton”.

NOT: (bknz. PPAP )  Bu parodiyi izlememiş olanlar için yukardaki cümle garip gelecektir. Video  Pikotoro adlı şarkıcının viral videosunu içermekte. İlgisini çekmeyecek olanlara hatırlatmadır, saçma bir şey. Konuya dönelim tekrar.

Bir diğer örnek decorator deseni ile ile Proxy deseni aynı yapıya sahip olsalar da “intent” kullanılış amaçları farklıdır. Yani burada iki tasarım deseninden birini seçme işi, yazılımcının gereksinimleri değerlendirip karar vermesi ile ilişkilidir. Zaten tasarım desenleri konusunu karmaşık yapan kısımda bu sanırım.

Yoksa şurda bir abstract class’tan türemiş bir concrete class, factory’nın constructor’ın da parametre ile composition kullanır, base class’ın falan falan methodu override edilir… Nice karar ve hengamenin sonucunda “Live happily ever after, forever”. Bu implementasyon kısımları mesele değil. Asıl survivor, gereksinim analizinin karşısına geçmiş, “taktik maktik yok bam bam bam”, analizin istediği program için kendine lazım olan tasarım desenlerini seçebilendir.

Eyyorlamam bu kadar demeden önce kendini bu kavramlara adamış bir web-sitesi önerisi de yapacağım. Her desen ile ilgili UML şeması ve kaynak kodu içeren bir site : oodesign

Evet, eyyorlamam bu kadar.

keep_calm

Leave a Reply

Your email address will not be published. Required fields are marked *