Tasarım örüntüleri

Emre · 03-07-08, 17:35

Tasarım desenleri veya tasarım örüntüleri, ç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ına 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 etkiliş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 Desen Dili:Kentler, Binalar, Yapılar (A Pattern Language: Towns, Buildings, Construction ISBN 0-195-01919-9), 1979'da Ebedi Yapım Yöntemi (A Timeless Way of Building ISBN 0-195-02402-8) kitaplarını yayınlamıştır. Bu kitaplarda mimari desen örnekleri yanı sıra, bu 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 anılır olmuştur. 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.

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. Anafikir, 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.

Soyut Fabrika (Abstract Factory)
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)
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.

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)
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.

Yegane (Singleton)
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.

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

Köprü (Bridge)
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.
Bileşik (Composite)
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.

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

Vitrin (Façade)
Karmaşık bir yapının bir arada tutularak tek bir arayüz üzerinden kullanımına olanak sağlar.

Sineksıklet (Flyweight)
Ç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.

Vekil (Proxy)
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.

Sorumluluk(-lar) Zinciri (Chain of Responsibility)
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.

Komut (Command)
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.

Yorumlayıcı (Interpreter)
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.

Yineleyici (Iterator)
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.

Arabulucu (Mediator)
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.

Yadigar (Memento)
Yadigar 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.

Gözlemci (Observer)
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.

Durum (State)
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.

Strateji (Strategy)
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.

Kalıp Yordamı (Template Method)
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.

Ziyaretçi (Visitor)
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 tabanlı programlama olarak bilinen kavramların, daha önceki programlama dillerinde tasarım örüntüsü olarak tavsiye edilen kavramlar olduklarını, ama nesne tabanlı programlama dillerinini çı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.

Bakınız..

Bilgisayar Bilimleri
Yazılım Mühendisliği

.:AnİmE sTyLe:. · 12-07-08, 15:26

istanbulda yaklaşık4-5 yıl içerisinde anime tasarımı bölümü üniversitelerde olur mu?,bildiğim kadaryla yalnız eskişehir anadolu üniversitesinde bulunmakta

03-07-08, 17:35	#1 (permalink)
Emre ArizMend> Giriş Tarihi: 01-03-2006 Yaş: 18 Mesajlar: 15,296 Blog Mesajları: 3 Rep Puanı: 98896429 Rep Gücü: 989150	Tasarım örüntüleri Tasarım desenleri veya tasarım örüntüleri, ç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ına 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 etkiliş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 Desen Dili:Kentler, Binalar, Yapılar (A Pattern Language: Towns, Buildings, Construction ISBN 0-195-01919-9), 1979'da Ebedi Yapım Yöntemi (A Timeless Way of Building ISBN 0-195-02402-8) kitaplarını yayınlamıştır. Bu kitaplarda mimari desen örnekleri yanı sıra, bu 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 anılır olmuştur. 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. 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. Anafikir, 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. Soyut Fabrika (Abstract Factory) 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) 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. 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) 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. Yegane (Singleton) 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. Uyumlayıcı (Adapter) Farklı kaynaklardan gelen nesne ya da sınıfların arayüzlerini uyumlandırmak amacıyla kullanılır. Köprü (Bridge) 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. Bileşik (Composite) 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. Dekoratör (Decorator) Bir nesneye, nesneyi değiştirmeden yeni sorumluluklar eklenmesini sağlar. Alt sınıflama yapmadan nesnelerin işlevlerinin geliştirilmesini olası kılar. Vitrin (Façade) Karmaşık bir yapının bir arada tutularak tek bir arayüz üzerinden kullanımına olanak sağlar. Sineksıklet (Flyweight) Ç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. Vekil (Proxy) 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. Sorumluluk(-lar) Zinciri (Chain of Responsibility) 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. Komut (Command) 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. Yorumlayıcı (Interpreter) 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. Yineleyici (Iterator) 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. Arabulucu (Mediator) 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. Yadigar (Memento) Yadigar 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. Gözlemci (Observer) 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. Durum (State) 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. Strateji (Strategy) 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. Kalıp Yordamı (Template Method) 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. Ziyaretçi (Visitor) 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 tabanlı programlama olarak bilinen kavramların, daha önceki programlama dillerinde tasarım örüntüsü olarak tavsiye edilen kavramlar olduklarını, ama nesne tabanlı programlama dillerinini çı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. Bakınız.. Bilgisayar Bilimleri Yazılım Mühendisliği

12-07-08, 15:26	#2 (permalink)
.:AnİmE sTyLe:. <marquee>kooop</mar Giriş Tarihi: 12-07-2008 Yer: 6 underground Mesajlar: 147 Rep Puanı: 21794 Rep Gücü: 223	C: Tasarım örüntüleri istanbulda yaklaşık4-5 yıl içerisinde anime tasarımı bölümü üniversitelerde olur mu?,bildiğim kadaryla yalnız eskişehir anadolu üniversitesinde bulunmakta

Konu Araçları
Çıktı Görüntüsünü Göster Sayfayı E-posta İle Yolla