TASARIM KALIPLARI TASARIM DESENLERİ TASARIM ÖRÜNTÜLERİ TASARIM ŞABLONLARI 1 Tasarım Kalıpları Nedir? Tasarım kalıpları; uzmanların yeni sorunları çözmek için geçmişte çalıştıkları çözümlerin uygulamalarının iyi belgelenmiş halidir. Tasarım kalıplarının arkasındaki düşünce, yazılım geliştirilirken sıklıkla karşılaşılan problemler için sunulan genel çözümler için standartlaşmış bir yol geliştirmektir. 2 Tasarım Kalıpları Avantajları 1. Zamanla, kalıpların kataloglarını yapabilir. Bu sayede, yazılım geliştirmeye yeni başlayanların yıllar geçtikçe kazanılan tecrübeden daha etkili bir şekilde yararlanması sağlanır. 2. Kalıpların standartlaştırılması, tüm geliştiricilerin (profesyoneller, yeni başlayanlar veya uzmanların) kararlarını daha kolay vermesini sağlamaktadır. 3. Tasarım kalıpları ortak bir kelime haznesi sağlar. Bu, geliştiriciler arasındaki iletişimi daha da kolay hale getirir. Bir tasarımı detaylıca açıklamaktansa, planları açıklamak için kalıp adını kullanabilir. 3 Tasarım Kalıpları Avantajları 4. Kalıplar birbirleri ile ilişkilendirilebilir, böylece geliştiriciler projelerinde hangi kalıpların birlikte bulunması gerektiğini kolayca anlayabilir. 5. Tasarım Kalıpları nesneye yönelik programlama topluluğu aracılıyla tecrübe paylaşımı için etkili bir yöntem sunmaktadır. Örneğin; C++, Smalltalk, C# yada Java programlama dillerinde kazanılan bilgiler, Web projelerinde ortaya çıkan uzmanlık gibi öğrenilen bilgiler biriktirebilir ve bunlar diğer geliştiricilerle paylaşılabilir. 4 GEÇMİŞTEN GÜNÜMÜZE YAZILIM MİMARİLERİ 5 Anti Kalıplar (Anti-Patterns) 6 Anti Kalıplar (Anti-Patterns) Anti-Pattern: Yazılımsal bir problemi, bilinen ve doğru çözüm olarak kabul edilmiş bir kalıbı kullanmadan ve özgün bir yöntemle çözmek anlamında kullanılmaktadır. İlk bakışta mükemmel gibi görünen bu çözümler sonradan sıkıntılar doğurmaktadırlar. 7 Anti Kalıplar (Anti-Patterns) • AntiPattern’lerin en tehlikeli tarafı ürün geliştirme süreçlerinde ve vakalarda en uygun çözüm yolu olarak düşünülmeleridir. • AntiPattern kavramlarını bilmek, yazılım geliştirme sürecinde karşılaşılabilecek ciddi problemleri önceden tahmin edebilmeyi sağlar ve tedbir almayı kolaylaştırır. 8 Anti Kalıplar (Anti-Patterns) •Anti-patternlerin kullanılması yanlıştır. •Kısa vadede hızlı bir çözüm gibi görünseler de, genelde yazılım mimarisinde uzun vadeli sıkıntılara yol açmaktadırlar. 9 Anti-Pattern Örnekleri • • • • • • • Magic Push button Spagetti Coding Lasagna Coding Kopyala-Yapıştır Programlama God Object (Tanrısal Nesne) Golden Hammer (Altın Çekiç) ve diğerleri… 10 1. Magic Push button • Herhangi bir soyutlama yapılmaksızın görsel nesnelerin arkasında kodlamanın yapılmasıdır. Buna buton click programcılığı denmektedir. • Bu kalıp GUI(GraphicalUserInterface) tipindeki uygulamalarda daha fazla ortaya çıkar. • Ara yüz tarafı ile iş mantıkları genellikle buton gibi bir kontroller arkasına gömülür. 11 2.Spagetti Coding Bakım ve değişikliğin yapılamayacak kadar karışık yazılmış kodlama türüne bu ad verilmektedir. Nesne yönelimli olmayan dillerde daha sık rastlanır. Metotlar daha çok süreç odaklı yazılır hatta süreç adları olarak isimlendirilir. 12 2.Spagetti Coding • Nesneler arasında neredeyse hiç ilişki yoktur. • Çoğu metot parametre almaz ve global seviyedeki sınıf değişkenlerini oluşturmakta kullanılır. • Kodun yeniden kullanılabilirliği zordur. • OOP temel özellikleri (kalıtım, çok biçimlilik, soyutlama)kullanılmaz. 13 3.Lasagna Coding • Gereğinden fazla sayıda katmana sahip uygulama geliştirilmesine denmektedir(Aşırı çok katmanlı uygulama). • Çok katman, çok sayıda irili ufaklı class, okunabilirliği, anlaşılması ve değiştirilmesi zor bir yazılımın ortaya çıkmasına neden olur. 14 4.Kopyala-Yapıştır Programlama • Daha genel, kapsamlı bir çözüm üretmek yerine, var olan kodları kopyalayarak geliştirme yolunu tercih etmektir. • Çoğunlukla bir çözüm için yazılımın herhangi bir yerinde uygulanan bir kod parçasının, ihtiyaç olunan başka bir yerde aynen kopyalanarak kullanılmaya devam etmesi olarak tanımlanır. • Bu anti-pattern kod tekrarlarına neden olmaktadır. 15 4.Kopyala-Yapıştır Programlama •Doğal sonuç olarak bir değişiklik olması halinde kodun çoğaltıldığı yerlere gidilmesi de gerekecektir. •Güncellemeler için fazla maliyetli çabalar sarf edilebilir. •Hatalar gözden kaçabilir ve uygulamanın yanlış çalışma riski giderek artabilir. •Söz konusu parçaları soyutlayıp, nesne yönelimli dil temellerine uygun olacak şekilde ayrıştırmak önemlidir. 16 5.God Object (Tanrısal Nesne) 17 5.God Object (Tanrısal Nesne) • Gereğinden çok şey bilen ve yapabilen sınıflara denmektedir. 18 5.God Object (Tanrısal Nesne) • Bu sınıflar çok fazla veriye sahiptir ve uygulamanın ana sınıfı gibi algılanabilmektedir. Bu kötü bir tasarımdır. 19 5.God Object (Tanrısal Nesne) Bu durumda tüm iş yükünü üstlenen sınıfların bakımı, genişletilmesi, iş mantıklarının kolayca okunur olarak içerisinde yer alması oldukça zorlaşır. Karmaşıklığın yanında, belleğe yüklenmesi zaman alan nesneler ortaya çıkar. 20 6.Golden Hammer (Altın Çekiç) • Tüm yazılımların SOA(Service Oriented Architecture) mimari bütünü içerisinde ele alınması gerektiğini düşünmek bu duruma örnek olarak verilebilir. • En sık görülen Anti-Pattern’ler arasında yer alır. 21 6.Golden Hammer (Altın Çekiç) • Söz konusu nedenlerinden gelişmelerden olmamasıdır. durumun birisi, ekiplerin oluşmasının teknolojik haberdar • Var olan bir çözüm yerine ondan daha kötü olan özel bir çözüm üretme hatasına düşmektir. 22 6.Golden Hammer (Altın Çekiç) • Bazı yazılım problemlerinin çözümünde kullanılacak olan yollar zaten standart ve bellidir. Üstelik bu çözümler için standart hale gelmiş mimari yaklaşımlar, ürünler ve alt yapılar (Frameworks) mevcuttur. • Problemin bu tip yardımcılar ile çözülemeyeceğini düşünüp sıfırdan bir çözüm üretilmeye başlandığı hal tekerleğin yeniden keşfi olarak düşünülür. 23 GoF (Gang of Four) Sistematiği GoF Kalıpları Creational Patterns Structural Patterns Behavioral Patterns Nesne yaratılışına ait Yapısal Davranışsal Kalıplar Kalıplar Kalıplar 24 GoF (Gang of Four) Sistematiği Creational Patterns Nesne yaratılışına ait Kalıplar Kalıplar Abstractfactory Builder Factorymethod Prototype Singleton 25 Creational Patterns Nesne Yaratılışına Ait Kalıplar • Bu gruptaki kalıplar, bir yada birden fazla nesnenin oluşturulması ve yönetilmesiyle alakalı kalıplardır. 26 GoF (Gang of Four) Sistematiği Structural Patterns Yapısal Kalıplar Adapter Bridge Decorator Facade Proxy 27 Structural Patterns Yapısal Kalıplar • Structural Patterns : Bu gruptaki tüm desenler nesnelerin birbirleriyle aralarında olan ilişkileri temel alarak tasarlanmıştır. 28 GoF (Gang of Four) Sistematiği Behavioral (Davranışsal) Kalıplar Chainofresponsibility Command Interpreter Iterator Mediator Memonto Observer State Strategy Visitor 29 Behavioral (Davranışsal) Kalıplar • Behavioral Patterns : Bu gruptaki kalıplar, belli bir işi yerine getirmek için çeşitli sınıfların birbirleriyle ne şekilde etkileşimli olarak davranacağını belirleyen kalıplardır. 30 Creational (Nesne Yaratılışına Ait) Kalıplar • Creational kalıplar, yazılım nesnelerinin(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. 31 Creational (Nesne Yaratılışına Ait) Kalıplar • 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. 32 Creational (Nesne Yaratılışına Ait) Kalıplar • 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. Creational kalıpları bu zorlukları aşmak amacıyla kullanılabilecek yazılım kalıpları içerir. • Yaratım kalıpları, 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. 33 Factory Method (Fabrika Tasarım Kalıbı) •Günlük hayatta bazı varlıklar yada nesnelerin yaratılışları basittir ve bu tür nesneleri kendimiz bile yaratabiliriz. Örneğin basit bir zili evde kendi kendimize yapabiliriz. •Oysa bazı varlıklar veya nesneler ise oldukça karmaşık süreçlerden geçilerek yaratılmaktadır. •Sözgelişi evde bir televizyon yapamayız. Ya da evde kendimiz para basamayız. Bu tür nesneleri özel fabrikalar-üretimin detaylarını tüketiciden gizleyerek-üretmekte ve tüketiciler de fabrikaların ürettiği bu nesneleri kullanmaktadırlar. 34 Factory Method (Fabrika Tasarım Kalıbı) •Nesne yönelimli programlama açısından da benzer bir durum söz konusudur. •Bazı nesneler doğrudan kullanıcısı tarafından yaratılabilmektedir. • Bunun anlamı; sınıfın başlangıç fonksiyonunu (new operatörü) kullanarak nesnenin yaratılmasıdır. 35 Factory Method (Fabrika Tasarım Kalıbı) • Ancak bazı nesnelerin (Product) kullanıcı(Client) olarak erişebileceğimiz başlangıç fonksiyonları bulunmamaktadır. 36 Factory Method (Fabrika Tasarım Kalıbı) •Client olan nesne Factory nesnesini kullanarak ihtiyacı olan Product nesnesini elde eder. •İstenen tipte yeni nesne oluşturma sürecinin Factory sınıfına aktarılması ile birlikte nesne üretme ve initialize etme süreci client’tan soyutlanmış olur. •Bu sayede client; uygulama içerisinde tamamen kendi rolüne odaklanmış olur. Çünkü yeni nesnenin nasıl oluşturulacağına dair detaylardan soyutlanmış olur. Bunları bilmek zorunda değildir. 37 Factory Method (Fabrika Tasarım Kalıbı) Factory Pattern genel olarak: • İstenen tipte nesne oluşturma sürecini Client’ın bu konuda detay bilgi sahibi olmadan gerçekleştirilmesini sağlar. • Yeni oluşturulan nesneye bir interface ile referans edilerek ulaşılmasını sağlar. 38 Factory Method (Fabrika Tasarım Kalıbı) Factory Method sınıf diyagramı 39 Factory Method (Fabrika Tasarım Kalıbı) • Product: Factory tarafından yaratılan nesnelerin arayüzü • ConcreteProduct: Product arayüzünü implemente eden sınıf. Bu sınıfın nesneleri ConcreteCreator tarafından yaratılır. • Creator: Factory metodunu/metotlarını (factoryMethod) tanımlayan arayüz. • ConcreteCreator: Creator sınıfını genişleten factoryMethod için bir implementasyon sağlayan sınıf . ve 40 Örnek: SekilFactory • ISekil arayüzünü ve bu arayüzü implemente eden somut sınıfları (Kare,Cember,Dikdortgen) yaratınız. • Sonrasında factory sınıfı olan SekilFactory sınıfını yaratınız. • Program sınıfında SekilFactory sınıfından bir Sekil nesnesi elde edebilecek şekilde SekilFactory sınıfını tanımlayınız. • Program sınıfında gereken nesnenin tipini (Cember,Kare,Dikdortgen) bilgi olarak geçebilecektir. 41 Örnek: SekilFactory-devam UML sınıf şeması: 42 Örnek: SekilFactory-devam 1.İlk olarak ISekil arayüzünü yaratırız. ISekil.java 43 Örnek: SekilFactory-devam 2.Sonrasında ISekil arayüzünü implemente eden somut sınıfları yaratırız. Kare.java 44 Örnek: SekilFactory-devam 2.Sonrasında ISekil arayüzünü implemente eden somut sınıfları yaratırız. Cember.java 45 Örnek: SekilFactory-devam 2.Sonrasında ISekil arayüzünü implemente eden somut sınıfları yaratırız. Dikdortgen.java 46 Örnek: SekilFactory-devam 3.Geçirilen bilgiye göre ISekil arayüzünü implemente eden sınıfların nesnelerini yaratan SekilFactory sınıfını ve getSekil(ESekilTur sekiltipi) metotunu oluşturunuz. 47 Örnek: SekilFactory-devam SekilFactory.java ESekilTur.java 48 Örnek: SekilFactory-devam 4.Şeklin tipi gibi bir bilgiyi geçirerek somut sınıflardan nesne elde etmek için SekilFactory sınıfını kullanırız. Program.java 49 FactoryMethod(devam...) Factory tasarım kalıbında, istemciye normal oluşturma mantığına maruz bırakmadan nesne oluşturulmasına olanak sağlanır ve yeni yaratılan nesneye ortak bir arayüz kullanarak erişilebilir. 50 Örnek2: ProductFactory 51 Örnek2: ProductFactory 1.Iproduct ara yüzünü yaratınız. IProduct.java 52 Örnek2: ProductFactory 2.ProductOne somut sınıfını yaratınız. ProductOne.java 53 Örnek2: ProductFactory 2.ProductTwo somut sınıfını yaratınız. ProductTwo.java 54 Örnek2: ProductFactory 3.ProductFactory sınıfını yaratınız. ProductFactory.java 55 Örnek2: ProductFactory 4.Client sınıfını yaratınız. Client.java 56 Tasarım Kalıpları –II Bu bölümde; FacadeTasarım Kalıbı ile ilgili konular anlatılacaktır. 57 Facade–Cephe/ ÖnYüz Tasarım Kalıbı •Çoğu modern yazılım sistemi oldukça karmaşıktır. •Tasarım kalıpları uygulamaların yapımında yardımcı olmakta ve karmaşıklıkla başa çıkmak için işleri kolaylaştırmaktadır. 58 Facade–Cephe/ ÖnYüz Tasarım Kalıbı •Karmaşık sistemlerde, fonksiyonelite bir dizi ufak sınıflar arasında bölünerek başarılabilmektedir. •Eklenen sınıflar ayrıca sistemin ufak parçalara ayrılmasının bir sonucu olarak da üretilebilirler. •Bir sistemi birkaç alt sisteme bölmek karmaşık sistemlerle başa çıkılmasında yardımcı olur ve çalışmanın parçalanmasına olanak sağlar. •Bir sistemi belirli bir sayıdaki özel sınıflara bölmek, iyi bir nesneye yönelimli tasarım pratiğidir. 59 Facade–Cephe/ ÖnYüz Tasarım Kalıbı •Fakat, bir sistemin içerisinde çok fazla sayıda sınıfın olması sakıncalı olabilir. •Çok fazla alt sisteme sahip olan bir sistemi kullanan istemciler daha fazla nesne ile başa çıkmak zorundadır. •Kullanıcılara yüzlerce yapılandırma seçeneği sunulduğunda, kullanıcıların kafası karışır. 60 Facade–Cephe/ ÖnYüz Tasarım Kalıbı •Bu duruma bir örnek olarak bir araba üreticisi düşünelim ve her türlü detayı kullanıcının opsiyonuna bırakmış olsun. •Örneğin aracın yakıtı yanarken kullanacağı hava/gaz oranını ayarlanmasını yada aracın içerisindeki ateşleme sisteminin nasıl işletilmesi gerektiğini sürücünün tercihine bırakıldığını hayal edelim. 61 Facade–Cephe/ ÖnYüz Tasarım Kalıbı •Bu durumda otomobilin her seferinde ayarlanması gerekir ve bu çok pratik değildir. •Sürücü olarak istenilen tek şey aracın anahtarını takmak ve aracı çalıştırmaktır. •Sistemin geriye kalanı sürücünün yerine halledilmelidir. Bir istemciye sadece birkaç seçenek fayda sağlamaktadır, yüzlercesi veya binlercesi değil. 62 Facade–Cephe/ ÖnYüz Tasarım Kalıbı • Facade, bu seçenekleri sağlayabilir ve hangi alt sistemin çağırılacağına karar verebilir. • Normalde Facade işin çoğunu alt sistemlere atar, fakat birkaç işi kendisi de yapabilmektedir. • Facade’ in asıl amacı alt sistemlerin saklanması değildir. 63 Facade–Cephe/ ÖnYüz Tasarım Kalıbı • Facade Tasarım Kalıbının amacı; bir dizi alt sistem için bir arayüz sağlamaktır. • Daha ayrıntılı seçeneklere ihtiyaç duyan istemciler alt sistemlerle etkileşime geçebilmelidir. 64 Facade–Cephe/ ÖnYüz Tasarım Kalıbı Örnek: Seyahat Acentesi OtelRezervasyon ve UcusRezervasyon sınıflarını Facade tasarım kalıbını kullanarak sınıfları ayrı ayrı kullanmaya gerek kalmayacak şekilde bir Seyahat sınıfı yaratalım. 65 Facade–Cephe/ ÖnYüz Tasarım Kalıbı Örnek: Seyahat Acentesi Seyahat Program +otelRezervasyonu:OtelRezervazyon +seyahat:Seyahat +ucusRezervasyonu:UcusRezervazyon +UygunOtelveUcusListele(Date seyahatBaslangic,Date seyahatBitis):void UcusRezervasyon +gidisTarihi:Date +donusTarihi:Date +UygunUcuslariListele(Date gidis,Date donus):ArrayList<Ucus> OtelRezervasyon +rezervasyonBaslangicTarihi:Date +rezervasyonBitisTarihi:Date +UygunOtelleriListele(Date baslangic,Date bitis):ArrayList<Otel> Ucus +gidisTarihi:Date +donusTarihi:Date +Firma:String +ucusNo:String Otel +ad:String +odasayisi:int +vergiNumarasi:int +sezonBaslangicTarihi:Date 66 Facade–Cephe/ ÖnYüz Tasarım Kalıbı Örnek: Seyahat Acentesi Otel.java 67 Facade–Cephe/ ÖnYüz Tasarım Kalıbı Örnek: Seyahat Acentesi Ucus.java 68 Facade–Cephe/ ÖnYüz Tasarım Kalıbı Örnek: Seyahat Acentesi OtelRezervasyon.java 69 Facade–Cephe/ ÖnYüz Tasarım Kalıbı Örnek: Seyahat Acentesi UcusRezervasyon.java 70 Facade–Cephe/ ÖnYüz Tasarım Kalıbı Örnek: Seyahat Acentesi Seyahat.java 71 Facade–Cephe/ ÖnYüz Tasarım Kalıbı Örnek: Seyahat Acentesi Program.java 72 Facade–Cephe/ ÖnYüz Tasarım Kalıbı Örnek: SekilCizici void Ciz() fonksiyonuna sahip ISekil arayüzünü implemente eden Kare, Dikdortgen ve Cember sınıflarının (sınıfına bağlı kalmadan) Ciz() metodunu kullanımını sağlayan SekilCizici sınıfını yaratınız. 73 Facade–Cephe/ ÖnYüz Tasarım Kalıbı Örnek: SekilCizici UML sınıf diyagramı: Program +sekilCizici:SekilCizici <<Interface>> ISekil SekilCizici +Ciz():void -cember:Isekil -dikdortgen:Isekil -kare:Isekil <<realize>> Kare Cember +Ciz():void +Ciz():void +CemberCiz():void +KareCiz():void +DikdortgenCiz():void +SekilCizici():void Dikdorgen +Ciz():void 74 Facade–Cephe/ ÖnYüz Tasarım Kalıbı Örnek: SekilCizici ISekil.java 75 Facade–Cephe/ ÖnYüz Tasarım Kalıbı Örnek: SekilCizici Kare.java 76 Facade–Cephe/ ÖnYüz Tasarım Kalıbı Örnek: SekilCizici SekilCizici.java 77 Facade–Cephe/ ÖnYüz Tasarım Kalıbı Örnek: SekilCizici Program.java 78 KAYNAKLAR • Aykut Taşdelen, C++, Java ve C# ile UML ve Dizayn Paternleri, Pusula Yayıncılık, İstanbul, 2014 • Eric Freeman, Head First Design Patterns, O'Reilly Media, 2004 • Stephen Stelting& Olav Maassen, Applied Java™ Patterns, Prentice Hall PTR, 2001 • http://www.AlgoritmaveProgramlama.com • http://www.tutorialspoint.com/ • http://www.buraksenyurt.com/post/AntiPatterns-DersNotlarc4b1m.aspx • http://www.kurumsaljava.com/ 79