Tasarım örüntüleri

Tasarım desenleri, tasarım kalıpları, tasarım örüntüleri veya tasarım şablonları, çok rastlanan, birbirine benzer sorunları çözmek için geliştirilmiş ve işlerliği kanıtlanmış genel çözüm önerileridir.

Yazılım tasarım desenleri

Yazılım tasarım örüntüleri, yazılım tasarımı sırasında sıkça karşılaşılan, birbirine benzer sorunları çözmek için geliştirilmiş ve işlerliği kanıtlanmış genel çözüm önerileridir. Genel olarak yazılım tasarım örüntüleri programlama dillerinden bağımsız olarak tanımlansalar da, nesneye yönelimli programlama dillerine uygun yazılım tasarım örüntüleri daha çok bilinir. Bu örüntüler, nesneler ve sınıflar arasındaki ilişkileri ve etkileşimleri gösterirler. Programcı bir tasarım örüntüsünü elindeki soruna bakarak özelleştirip kullanabilir.

Tarihçe

Tasarım örüntülerinin temelleri Mimar Christopher Alexander'ın 1970 sonlarında başlatığı çalışmalara dayanmaktadır. Alexander 1977'de Bir Desen Dili: Şehirler, Binalar, Yapılar (A Pattern Language: Towns, Buildings, Construction, ISBN 0-19-501919-9), 1979'da Ebedî Yapım Yöntemi (A Timeless Way of Building, ISBN 0-19-502402-8) kitaplarını yayınlamıştır. Bu kitaplarda tasarın örüntülerinin üst seviyesi örüntüleri içeren mimarî desen örneklerinin yanı sıra desenlerin nasıl belgeleneceği de konu edilmiştir.

1987'deki uluslararası Nesneye Yönelik Programlama, Sistemler, Diller ve Uygulamalar (OOPSLA, Object Oriented Programming, Systems, Languages, and Applications) konferansına kadar desenlerle ilgili bir çalışma ortaya çıkmamış. Bu tarihten sonra ise Grady Booch, Richard Helm, Erich Gamma ve Kent Beck başta olamak üzere örüntülerle ilgili makale ve sunumlar yayınlamışlardır. 1994'de Erich Gamma, Richard Helm, Ralph Johnson ve John Vlissides tarafından yayınlanan Tasarım Örüntüleri: Tekrar kullanılabilir Nesneye Yönelik Yazılımın Temelleri (Design Patterns: Elements of Reusable Object-Oriented Software, ISBN 0-201-63361-2) tasarım örüntülerinin yazılımda kullanılmasında dönüm noktası olmuştur.

Dörtlü Çete (Gang of Four, kısaca GoF) yazılım tasarım desenleri

Yazılım tasarım örüntüleri 1994 tarihinde Tasarım Örüntüleri: Tekrar kullanılabilir Nesneye Yönelik Yazılımın Temelleri (Design Patterns: Elements of Reusable Object-Oriented Software, ISBN 0-201-63361-2) adıyla yayınlanan kitap ile yaygınlaşmaya başlamış. Kitabın yazarları Erich Gamma, Richard Helm, Ralph Johnson ve John Vlissides bilgisayar bilimleri çevresinde Dörtlü Çete olarak de bilinmektedir. Dörtlü Çete, isimi kitabın isminin uzun olmasından dolayı konuyla ilgili e-postalarda kısaltma yapılarak, yazarları kastederek, kitabın "Dörtlü Çetenin Kitabı" (Book of GoF) olarak anılmasıyla ortaya çıkmıştır.

Tasarım desenleri sınıfları

Dörtlü Çete'nin Tasarım Örüntüleri kitabı (ISBN 0-201-63361-2) tasarım örüntülerini üç sınıfa ayırır, fakat bu sınıfları birbirinden ayıran keskin kriterler yoktur.

Yaratım örüntüleri

Yaratım örüntüleri, yazılım nesnelerinin (ya da başka bir değişle sınıf örnekleri - class instances) nasıl yaratılacağı hakkında öneriler sunar. Ana fikir, iyi bir yazılımın, içinde barındırdığı nesnelerin nasıl yaratıldığından bağımsız olarak tasarlanması gerekliliğidir. Diğer bir deyişle, nesnelerin nereden ve nasıl yaratıldığı, ait oldukları yazılımın işleyişini etkilememeli; yeni özellikler eklenmesine ve değişikliklere karşı sorun oluşturmamalıdır.

Yazılım sistemleri geliştikçe, nesnel bileşimler (object composition), sınıf kalıtımına (class inheritence) göre daha fazla önem kazanır. Bunun nedeni, yazılım sistemleri için basit temel davranış (behavior) şekillerinin tanımlanması üzerine kurulu tasarımların, sabit davranışlara dayalı tasarımlara göre daha esnek olmasındandır. Diğer bir deyişle, nesnelere davranışların bileşim olarak eklenmesi, daha sonra bu davranışların yazılımın gelişimine göre değiştirilmesine olanak sağlar. Bu durumda, geliştirilen yazılım için gereken temel davranış şekillerine dayalı bir tasarım, nesne arayüzleri (interface) değiştirmeden farklı ya da daha karmaşık davranışların kullanılabilmesini olanaklı kılar.

Ancak, nesnel bileşimler yoluyla temel davranışları sağlayan nesnelerin örneklenmesi, ana ya da kalıtım yoluyla davranış değişikliğine uğratılarak türetilmiş sınıflardan nesne oluşturmak daha zordur. Yaratım örüntüleri bu zorlukları aşmak amacıyla kullanılabilecek yazılım örüntüleri içerir.

Yaratım örüntüleri, hem hangi somut sınıfların (concrete class) nesne örneklemesinde kullanıldığını, hem de bu örneklerin nasıl yaratılıp bir araya getirildiğini yazılım sisteminden saklarlar.

• Fabrika yöntemi (factory method)

Nesne yaratımı için kullanılan tek arayüz altında nesnenin nasıl yaratılacağını kalıtım yoluyla alt sınıflara bırakarak, arayüzle nesne yaratım işlevlerini birbirinden ayırır.

• Örnek (prototype pattern)

Karmaşık ve/veya pahalı sınıflardan nesne yaratırken, yeni nesnelerin baştan yaratılması yerine, mevcutlarından örnekleyerek yaratılmasını sağlar. Bu sayede yeni nesneler kolayca ve kaynaklar gereksiz yere meşgul edilmeden yaratılırlar.

• Soyut fabrika (abstract factory pattern)

Tek arayüz ile bir nesne ailesinin farklı platformlarda yaratılmasını olanaklı kılar. Bu sayade yazılım uygulaması farklı platfromlara davranış değişikliğine uğramadan taşınabilir. Soyut fabrika kalıbı tek arayüz altında hangi somut sınıfların kullanıldığını saklar.

• Yapıcı (builder pattern)

Karmaşık bir nesne grubunun tek arayüz üzerinden gerektiğince parça parça yaratılmasını sağlar. Kullanıcı nesne grubunu kullandıkça nesne grubu gereken yönde yapılanır. Kullanılmayan parçalar gereksiz yere yaratılarak kaynak harcamaz.

• Yegâne (singleton pattern)

Bir sınıftan sadece bir tane nesne yaratılacak şekilde kısıtlama sağlar. Söz konusu nesneye uygulamanın her yerinden ulaşılabilir. Nesne ilk kez kullanılana dek yaratılmayabilir.

Yapısal örüntüler

Yapısal örüntüler sınıfların ve nesnelerin bileştirilerek daha geniş yazılım yapılarının kurulmasına olanak sağlayan öneriler sunar. Sınıf yapı örüntüleri ve nesne yapı örüntüleri olmak üzere ikiye ayrılır.

Sınıf yapı örüntüleri kalıtım kullanarak sınıf arayüzlerini ya da uygulamaları bileştirerek yapıları genişletir. Nesne yapı örüntüleri ise nesnelerin bileştirilerek yeni işlevler kazanma yollarını gösterir.

• Bileşik (composite pattern)

Nesnelerin parça-bütün ilişkisi içinde ağaç yapısı ile bir araya getirilerek bileştirilmesine ve bu bileşiğe tek arayüzden ulaşılmasına olanak sağlar. Bileşik yapı yeni nesneler eklenip çıkarılarak zamanla genişleyip daralabilir.

• Cephe (façade pattern)

Karmaşık bir yapının bir arada tutularak tek bir arayüz üzerinden kullanımına olanak sağlar.

• Dekoratör (decorator pattern)

Bir nesneye, nesneyi değiştirmeden yeni sorumluluklar eklenmesini sağlar. Alt sınıflama yapmadan nesnelerin işlevlerinin geliştirilmesini olası kılar.

• Köprü (bridge pattern)

Hem arayüzün hem de somut uygulamanın birbirinden ayrılarak düzenlenmesine olanak sağlar. Arayüzün değişimi uygulamayı, uygulamanın değişimi arayüzü etkilemez. Her ikisi bağmsız olarak geliştirilebilir.

• Sinek siklet (flyweight pattern)

Çok sayıda benzer nesnenin yaratılması yerine, bir örnek nesneden görsel nesneler yaratarak kalabalık bir nesne yapısı kurulmasına olanak sağlar. Görsel nesnelerin durum değişkenleri nesnenin kendisi tarafından değil kullanıcı tarafından saklanır.

• Uyumlayıcı (adapter pattern)

Farklı kaynaklardan gelen nesne ya da sınıfların arayüzlerini uyumlandırmak amacıyla kullanılır.

• Vekil (proxy pattern)

Karmaşık, pahalı ve oluşturulması güç nesneleri kullanmak için arayüz taklidini olası kılar. Kullanılacak olan nesnenin fiziksel yerini kullanıcıdan saklayacak şekilde yönlendirme yapılmasını sağlar.

Davranış örüntüleri

Davranış örüntüleri işlevsel sorumlulukların nesneler arasında nasıl atanacağı ve yazılımın gerektirdiği çözüm yöntemlerinin nesnelerce nasıl kullanılacağı hakkında öneriler sunar. Davranış örüntüleri nesne ve sınıf kalıpları yanı sıra nesneler arasındaki iletişim ile ilgili örüntüler de sunar. Davranış örüntüleri tasarımcının nesneler arası iletişim ve iletişim yöntemlerine yoğunlaşmasını sağlar.

Aynen yapısal örüntülerde olduğu gibi, davranış örüntüleri de ikiye ayrılır: sınıf davranış örüntüleri ve nesne davranış örüntüleri.

Sınıf davranış örüntüleri kalıtım kullanarak davranışların sınıflar arasında dağıtılmasını olanaklı kılar. Nesne davranış örüntüleri ise nesne bileştirme yoluyla tek bir nesnenin kolayca sağlayamayacağı davranışların bir nesne grubu ile sağlanmasını olanaklı kılar.

• Arabulucu (mediator pattern)

Birbiri ile bağlatılı olarak çalışan nesnelerin aynı çatı altında tutularak tek bir noktadan(yani arabulucu tarafından) yönlendirilmesine olanak sağlar. Arabulucuya bağlı olan nesneler, durum değişikliklerini arabulucuya iletirler. Arabulucu uygulamanın gerektirdiği düzenleme ve sıra ile ilgili nesnelerden isteklerde bulunur. Üst seviye kullanıcı nesneler ise sadece arabulucu ile bağlantı kurarlar.

• Durum (state pattern)

Bir nesnenin davranışını durumuna göre değiştirmesine olanak sağlar. Kullanıcı açısından, nesne sınıfını değiştiriyormuş izlenimi verir. Uygulamanın gerektirdiği doğrultuda yeni davranışlar eklenip çıkarılmasına olanak sağlar. Kullanınıcı nesneler ise bu tür değişikliklerden etkilenmez.

• Gözlemci (observer pattern)

Bir grup nesnenin, gözlemciler, gözlem altındaki bir nesnede olan değişimlerden otomatik olarak haberdar olmasına olanak sağlar. Gözlem altındaki nesne, kimler tarafından izlendiğinden bağımsız olarak işlevini sürdürür. Zaman içinde yeni gözlemcilerin katılımı ya da ayrılması mümkündür. Bu sayede uygulama zaman içinde davranış değiştirebilir.

• Kalıp yordamı (template method pattern)

Bir yordamın çözüm kalıbı olarak kullanılmasına olanak sağlar. Kalıp üzerindeki bazı işlem adımları alt sınıflar tarafından işlenmesine olası kılar. Dolayısıyla ana kalıp değişmeksizin, bazı ara adımlar değişikliğe uğratılabilir. Kullanıcılar bu değişikliklerin farkında olmazlar.

• Komut (command pattern)

Kullanıcı(nesnel) isteklerinin nesnelere dönüştürülerek işlenmesini olası kılar. Bu sayede farklı kullanıcıların istekleri nesnel kayıtlara dönüştürülerek kuyruk ya da kayıtlarda tutulabilir. Bu sayede yapılan işlemlerin geriye dönüştürülmesine de olanak sağlanır.

• Sorumluluklar zinciri (chain of responsibility pattern)

Bir kullanıcı(nesnel) isteğinin birden fazla nesne tarafından değerlendirilerek karşılanmaya çalışılmasına olanak sağlar. kullanıcı tek arayüz üzerinden isteğini iletir. İstek zincire bağlı nesneler tarafından sıra ile ele alınarak karşılanmaya calışılır. İstek karşılanana dek zincir üzerinde bir nesneden diğerine aktarılır. Zaman içinde zincire yeni nesneler eklenmesi ya da çıkarılması mümkündür. Kullanıcı bu tür değişikliklerden arayüz sayesinde etkilenmez.

• Yorumlayıcı (interpreter pattern)

Karmaşık uygulamaların gereklerini yerine getirmek için tanımlanan sözde-dili işleyecek bir yorumlayıcı kalıbıdır. Sözde-dilin gramer kurallarını birer sınıf olarak tanımlayarak kolayca uygulanmasını sağlar. Gramer kuralları sınıflar olarak tanımlandığı için kolayca değiştirilerek geliştirilebilir.

• Yadigâr (memento pattern)

Yadigâr uygulama yazılımı içerisinde önemli roller üstlenen nesnelerin durumlarını saklamak ve gerektiğinde nesneleri geçmişteki durumlarına geri döndürmek ya da hatırlatmak için kullanılır.

• Yineleyici (iterator pattern)

Kitlesel bir nesnenin(Aggragate Object) altında bulunan nesnelere, nesnelerin nasıl temsil edildiklerine ya da gerçeklendiklerine bakılmaksızın, sırasıyla ulaşılmasını sağlar. Bu sayede farklı şekilde temsil edilen nesnelere tek bir arayüz üzerinden ulaşılabilir.

• Strateji (strategy pattery)

Aynı arayüz altında, aynı sorunu çözebilecek birçok çözüm yöntemi sınıfını saklayarak, kullanıcı nesnelerin hangi yöntemin kullanıldığından haberdar olmaksızın isteklerininin sağlanmasını olanaklı kılar. Kullanıcı nesneler aynı türden nesnelerle çalıştıklarını varsayarken, farklı davranış biçimleri ile karşılanırlar.

• Ziyaretçi (visitor pattern)

Bileşik bir yapı üzerine yeni işlemler eklenmesine olanak sağlar. Ziyaretçi nesne bileşik yapı içindeki nesneleri tek tek ziyaret ederek gerekli bilgileri toplayıp işleyerek kullanıcıya sunar.

Yazılım tasarım örüntülerine eleştiri

Bazı yazarlar, yazılım tasarım örüntülerinin sorunların çözümlerini olumsuz yönde etkilediği yönünde eleştirmektedir. Bazılarına göre de, yazılım örüntüleri programla dilinde veya metodolojisindeki kısıtlamaları ve sorunları göstermektedir ve örüntüyü tespit etmek son aşama olmamalıdır. Yeni programla dillerinde bu örüntüleri gerektirecek durumları engelleyecek çözümler dilin kendisinden sağlanmalıdır. Örneğin bu görüşün taraftarları nesne yönelimli programlamaya ait olarak bilinen kavramların, daha önceki programlama dillerinde tasarım örüntüsü olarak tavsiye edilen kavramlar olduklarını, ama nesne yönelimli dillerin çıkmasıyla bu kavramların dil içinde belirsiz bir şekilde kullanıldığını ve artık bir örüntü olmadıklarını savunmaktadırlar.