Herkese Selamlar! Ben Onur Yürüten. Bilkent Üniversitesi Bilgisayar Mühendisliği'nde 3. sınıfta okuyorum. E-Bergi'de yazmaya başlamış olmaktan büyük sevinç ve gurur duymaktayım. Umarım yazılarım bir şekilde size yarar sağlar...
Önkoşullar: UML ve OOA/D!
Tasarım desenlerini anlatırken çeşitli UML diyagramlarına da başvuracağım. Bu yüzden UML hakkında ufak da olsa fikir sahibi olmak isteyebilirsiniz. Bunun için E-Bergi'nin Ocak 2009 sayısındaki UML yazımızı okumanızı ve Nesne tabanlı analiz/tasarım hakkında çeşitli kaynakları da araştırmanızı tavsiye ederim!
Tasarım Deseni Nedir, Nerelerde Kullanılır ve Karşı-Desenlerin Genel Tanımı
Yaşamımızın pek çok öğesi, belli başlı tekrarlanan “desenler”den oluşmaktadır; örneğin tango dansında belirli hareket kalıplarını kullanırız, imza atarken kalemimizi bir kalıp içerisinde yönlendiririz. Bu kalıpların hepsi bizim ya da başka biri tarafından tasarlanmıştır. Yazılım mühendisliğinde de benzer şekilde tasarım desenleri kullanılmaktadır. Kısa ve net olarak tanımlamak gerekirse bir tasarım deseni, yazılım tasarımlarında sıklıkla ortaya çıkan belli bir problemin yeniden kullanılabilir (reusable) çözümüdür (Wikipedia). Bu bağlamda tasarım desenleri, insanların deneyimlerini birbirlerine ve gelecek nesillere aktarması açısından çok önemli bir rol oynamaktadır.
Bir tasarım deseni mümkün olduğu kadar genel, ve ilgilendiği sorun için doğru ve verimli bir çözümleme sunuyor olmalıdır. Tasarım desenleri tanımlanırken;
- Koşullar: Bu desenin uygulanacağı ortam ve ortamın koşulları
- Problem: Ortamdaki ana sorun, sorun çözülürken özellikle dikkat edilmesi gereken kısıtlar
- Çözüm: Etkili çözüm (tercihen UML Sınıf Şemaları aracılığıyla)
- Karşı-Desenler ve
- Diğer ilgili desenler tanıtılır.
Bazı tasarım denemeleri, her ne kadar belirtilmiş tasarım desenine benziyor olsa da, ya daha verimsizdir ya da tasarım deseninde öngörülen çözümü tam olarak yerine getiremezler. Bunlara, bu tasarım deseninin karşı-deseni (Anti-pattern) denir.
Bir tasarım desenini uygularken, onun karşı-desenlerinini oluşturabilecek koşullara dikkat etmeliyiz. Aksi takdirde tasarladığımız yazılım ya yanlış bir çözüm üretecektir ya da doğru çözümü üretebilmek için gerektiğinden fazla zaman ve yer kaplayacaktır. Ayrıca, tasarımlarımıza çıkan her problem tasarım desenleriyle çözülmesi gerektiğini de varsayamayız. Daha uygun çözümlerin de olabileceğini aklımızdan çıkarmamalıyız.
Bu uzun girişten sonra, sanırım biraz örnek sunmalıyım :)
Soyutlama-Rastlanış Deseni (Abstraction-Occurrence Pattern)
Ortam Koşulları:
Modellemek istediğimiz bir bilgi alanında, genellikle, çeşitli rastlanışlar bulunmaktadır. Bu rastlanışların belli bir kısmı birbiriyle ilintili özelliklere sahiptir; ancak birbirlerinden de önemli açılardan da farklılık taşımaktadırlar. Örneğin çeşitli üniversitelernin çeşitli bölümleri tarafından açılan dersler.
Bütün bu rastlanış kümelerini tasarım modelimizde - verileri gereksiz yere tekrarlamadan - nasıl ifade edebiliriz?
Çözüm:
İşte bu noktada, tasarım desenimiz uygulamaya geçirilir: Bu rastlanışlardaki ortak bilgi bir Soyutlamaya aktarılır ve ilgili Rastlanışlar bu Soyutlamayla, uygun bir şekilde ilintilendirilir.
DİKKAT !! Burada bahsedilen Soyutlama'nın nesne-tabanlı dillerde tanımlanmış _Soyut Sınıf_larla (örn: Java'daki abstract class veya interface) ilgisi yoktur. Onların kullanım amacı apayrıdır.
Bu genel çizimden yola çıkarak pek çok örnek çizim yapabiliriz; (örn: Dizi-DiziBölümü, Kitap-KütüphaneKaydı,...). İlk örneğimize dönecek olursak, farzedelim ki Türkiye'deki üniversitelerde verilen dersleri görüntüleyen bir sistem tasarlıyoruz. Ve yine farzedelim ki her ders rastlanışında bölümünün adını, kredi sayısını, haftalık ders sayısını, dersi verenleri, dersin projelerini, zorunlu olup olmadığını ve hangi üniversitede verildiğini tutmak istiyoruz. Bu duruma uygun olan şema yaklaşık olarak sağdakine benzeyecektir (sınıfların sadece özelliklerini, çalakalem bir şekilde yazdım):
Bu tasarım parçası sayesinde bir bilgisayar mühendisliği dersi ile matematik dersi gerekli yerlerde ayrışmış ve gerekli yerlerde birleşmiş oldu.
Karşı Desenler:
Soyutlama ve rastlanış arasında “kalıtım”(inheritence) ilişkisi kurmak: Bu durumda “Soyutlama”daki tüm bilgiler “Rastlanış”larda kopyalanmış olur. Bu da verilerin gereksiz yere tekrarlanmasından başka bir şey değildir. Ayrıca verilerin güncellenmesini korkunç bir şekilde zorlaştırır:
Rastlanışları hiç ifade etmemek: Bu durumda ise farklılıkları göstermeyen bir tasarım oluşur. Her ders için aynı sınıftan örnekleme yapar ve üniversite bilgilerini bu örneklemelerde gereksiz yere tekrarlamış oluruz.
Bir sonraki yazımda da Delegation Pattern hakkında yazmayı planlıyorum. Bir sonraki sayıya kadar, her şey gönlünüzce olsun...