Tasarım Desenleri(Design Patterns)

Tasarım desenleri hakkındaki çeviri notlarım

Kaynak: “Lethbridge/Laganière, lloseng.com, Design Patterns, 2005”.

Tekrar eden problemlere hazır ve doğruluğu onaylanmış çözümler sunma amacı ile hazırlanmış yapılardır.

Tasarım desenlerini tanımlarken şu bilgiler verilir:

Bağlam: Genel durum hakkında bilgi

Problem: Sorunun tanımı.

Kuvvetler: Çözüme dair sorunlar veya endişeler.

Çözüm: Önerilen çözüm yolu.

Anti-desenler: İşe yaramayan çözümler.

Benzer desenler: Benzer desenler.

Referanslar: Kimin geliştirdi veya ilham olduğu bilgisi.

Not: Tasarım desenleri ismi İngilizce olarak bilinmelidir ki çeviriden kaynaklı anlam kaymaları yaşanmasın. Ben yine de çevirilerini de yazacağım.

Temel 12 tasarım deseni:

Abstraction-occurrence(soyutlama-oluş):

Bağlam:
Genellikle bir etki alanı modelinde, bir dizi ilgili nesne (occurence) bulursunuz.
Böyle bir kümenin üyeleri ortak bilgileri paylaşırlar, ancak aynı zamanda önemli şekillerde birbirlerinden farklıdırlar.
Problem:
Bir sınıf diyagramında bu tür oluşum kümelerini temsil etmenin en iyi yolu nedir?
Kuvvetler:
Ortak bilgileri çoğaltmadan her bir olay kümesinin üyelerini temsil etmek istiyorsunuz.

General Hierarchy(genel hiyerarşi):

Bağlam:
Bir hiyerarşideki nesnelerin üzerinde bir veya daha fazla nesne (superiors) ve altlarında bir veya daha fazla nesne (subordinates) olabilir. Bazı nesnelerin astları olamaz.
Problem:
Bazı nesnelerin astlarının olamayacağı bir nesneler hiyerarşisini nasıl temsil edersiniz?
Kuvvetler:
Hiyerarşiyi temsil etmenin, belirli nesnelerin astlarına sahip olmasını engelleyen esnek bir yol istiyoruz. Bu nesnelerin birçok ortak özelliği ve işlemi olacaktır.

Player-role(oyuncu-rol):

Bağlam:
Rol, belirli bir bağlamdaki bir nesneyle ilişkilendirilen belirli bir özellik kümesidir. Bir nesne farklı bağlamlarda farklı roller oynayabilir.
Problem:
Bir oyuncunun rolleri değiştirebilmesi veya birden fazla role sahip olabilmesi için oyuncuları ve rolleri en iyi nasıl modellersiniz?

Kuvvetler:
Bir sınıftaki her bir ayrı rolle ilişkili bilgileri yakalayarak kapsüllemeyi geliştirmek arzu edilir. Çoklu kalıtımdan kaçınmak istiyoruz. Bir örneğin(instance) sınıfını değiştirmesine izin veremezsiniz.

Singleton(tekli):

Bağlam:
Yalnızca bir örneğinin bulunması gereken sınıflar kullanmak çok yaygındır (Singleton).
Problem:
Bir Singleton sınıfının birden fazla örneğini oluşturulmasının asla mümkün olmadığından nasıl emin olursunuz?
Kuvvetler:
Bir ortak yapıcının(constructor) kullanılması, birden fazla örneğin oluşturulmayacağını garanti edemez. Singleton örneğine, onu gerektiren tüm sınıflar da erişebilmelidir.

Observer(gözlemci):

Bağlam:
İki sınıf arasında bir ilişki oluşturulduğunda, sınıfların kodları ayrılamaz hale gelir. Bir sınıfı yeniden kullanmak istiyorsanız, diğerini de yeniden kullanmanız gerekir.
Problem:
Sınıflar arasındaki, özellikle farklı modüllere veya alt sistemlere ait olan sınıflar arasındaki, ara bağlantıyı nasıl azaltırsınız?
Kuvvetler:
Sistemin esnekliğini mümkün olan en üst düzeye çıkarmak istiyorsunuz.

Delegation(yetkilendirme):

Bağlam:
Bir sınıfta bir metod yazıyorsunuz. Başka bir sınıfın gerekli işlemi yapan bir metodu olduğunu görüyorsunuz. Miras kullanımı uygun değil çünkü ISA ilişkisi geçerli değil.
Problem:
Diğer sınıfta zaten var olan bir metodu en etkili şekilde nasıl kullanabilirsiniz?
Kuvvetler:
Metodları yeniden kullanarak geliştirme maliyetini en aza indirmek istiyorsunuz.

Adapter(adaptör):

Bağlam:
Bir miras hiyerarşisi oluşturuyorsunuz ve onu mevcut bir sınıfa dahil etmek istiyorsunuz. Yeniden kullanılan sınıflar genellikle kendi kalıtım hiyerarşilerinin bir parçasıdırlar.
Problem:
Metodları hiyerarşideki diğer yöntemlerle aynı işleve sahip ancak aynı imzaya sahip olmayan bir sınıfı yeniden kullanırken polimorfizm nasıl sağlanır?
Kuvvetler:
Çoklu mirasa erişiminiz yok veya kullanmak istemiyorsunuz.

Facade(cephe):

Bağlam:
Çoğu zaman, bir uygulama birkaç karmaşık paket içerir. Bu tür paketlerle çalışan bir programcı, birçok farklı sınıfı idare etmek zorunda kalır.
Problem:
Programcıların karmaşık bir paket üzerindeki görüşlerini nasıl basitleştirirsiniz?
Kuvvetler:
Bir programcının tüm bir alt sistemi anlaması ve kullanması zordur. Birkaç farklı uygulama sınıfı karmaşık paketin yöntemlerini çağırırsa, pakette yapılan herhangi bir değişiklik tüm bu sınıfların tam olarak gözden geçirilmesini gerektirecektir.

Immutable(değişmez):

Bağlam:
Değişmez nesne, oluşturulduktan sonra asla değişmeyen bir duruma sahip bir nesnedir.
Problem:
Örnekleri değişmez olan bir sınıfı nasıl yaratırsınız?
Kuvvetler:
Değişmez bir nesnenin ‘yasadışı’ olarak değiştirilmesine izin verilebilecek hiçbir boşluk olmamalıdır.
Çözüm:
Örnek değişkenlerin değerlerinin ayarlandığı veya değiştirildiği tek yerin değişmez sınıfın yapıcısı(constructor) olduğundan emin olun. Özelliklere erişen örnek metodların yan etkileri olmamalıdır. Aksi takdirde bir örnek değişkeni değiştirecek bir yöntem gerekliyse, sınıfın yeni bir örneğinin döndürülmesi gerekir.

Read-only Interface (yalnız-okuma arayüzü):

Bağlam:
Bazen belirli ayrıcalıklı sınıfların, aksi takdirde değişmez olan nesnelerin niteliklerini değiştirebilmesini istersiniz.
Problem:
Bazı sınıfların bir sınıfı salt okunur olarak gördüğü, diğerlerinin ise değişiklik yapabileceği bir durumu nasıl yaratırsınız?
Kuvvetler:
“Public”, “protected” ve “private” anahtar kelimeleri kullanarak erişimi kısıtlamak yeterince seçici değildir.
Erişimi herkese açık hale getirmek, hem okuma hem de yazma için herkese açık hale getirir.

Proxy(vekil):

Bağlam:
Çoğu zaman, bir sınıfın (ağır sınıfların) örneklerini oluşturmak zaman alıcı ve karmaşıktır. Nesneyi bellekte yaratmak zor ve zaman alıcıdır.
Problem:
Ağır sınıfların örneklerini oluşturma ihtiyacı nasıl giderilir?
Kuvvetler:
Bir etki alanı modelindeki tüm nesnelerin, bir sistemin çeşitli sorumluluklarını yerine getirirken programların kullanması için kullanılabilir olmasını istiyoruz. Aynı programın çalışma süresince birçok nesnenin varolmaya devam etmesi de önemlidir.

Factory(fabrika):

Bağlam:
Yeniden kullanılabilir bir çerçevenin nesneler yaratması gerekir; ancak oluşturulan nesnelerin sınıfı uygulamaya bağlıdır.
Problem:
Bir programcının böyle bir çerçeve üzerine kurulmuş bir sisteme uygulamaya özel yeni sınıf eklemesini nasıl sağlarsınız?
Kuvvetler:
Çerçevenin henüz bilmediği, uygulamaya özel sınıflar oluşturmasını ve bunlarla çalışmasını istiyoruz.
Çözüm:
Çerçeve, uygulamaya özel sınıfların oluşturulmasını özel bir sınıf olan Factory’ye devreder.
Fabrika, çerçevede tanımlanan genel bir arayüzdür.
Fabrika arabirimi, amacı genel bir sınıfın bazı alt sınıflarını oluşturmak olan bir yöntem bildirir.

-SON-

Kaynaklar:

Lethbridge/Laganière, lloseng.com, Design Patterns, 2005