Geçmişte bir mülakat öncesinde bir programlama görevi göndermişlerdi. Mülakatın da hayliyle bir kısmı bu programlama görevinde yaptıklarımın değerlendirmesiyle ilerliyordu. Görüşmeci arkadaş, mülakatın bir yerinde kullandığım Visitor desenini, sadece kullanmak için kullandığım hissine kapıldı ve hissiyatını da bana yansıttı aslında. Ben de o noktada bakış açımı açıklamak durumunda kalmıştım:
Bir çözüm oluştururken, bir desen ile tasarım yapmaya konsantre olmaktan ziyade (ki hatta ve hatta çok kapsamlı bir nesne modeli oluşturarak bile vakit kaybetmeden) , problemi küçük parçalara bölmeye çalışıyorum ve çözümüyle birlikte kodu ufaktan yazmaya başlıyorum. Zaten desene ihtiyaç da bir müddet sonra ortaya çıkıyor ve bu noktada kodu tekrar düzenleyerek ilerliyorum. Bu düzenleme de bana çok vakit kaybettirmiyor genellikle.
Bahsettiğim görev için çalışırken, daha henüz işe koyulduğumda, Visitor deseni yoktu ortalarda. Bir desenle açıklanmaya gerek olmayan bir nesne modeli vardı. Sonrasında hem terminolojik olarak nesne modelini bir kaç kelime açıklanabilmesi hem de sonra genişleyen modelde bir şablon ortaya koymasındaki avantajları ile sebebiyle Visitor desenine doğru çok da büyük olmayan bir değişlik yapmıştım.
Bütün bunlara anlattıklarıma rağmen, gene bir desenle direk açıklanabilecek ve tasarlanabilecek problem da karşımıza çıkabiliyor. Mesela Iterator (ki aslında kullandığımız programlama dillerinde doğal olarak desteklenen bir desen), Adapter, Observer gibi GOF desenleri bu noktada kendini hızlıca belli edebiliyor. Bunlar hemen ilk aklıma gelenler. Bazı zamanlar çözümün hangi desen ile açıklandığını, nesne modelini oluşturduktan sonra bile görebiliyor insan.
Hiç yorum yok:
Yorum Gönder