TASARIM KALIPLARI TASARIM DESENLERİ TASARIM ÖRÜNTÜLERİ TASARIM ŞABLONLARI

Transkript

1 TASARIM KALIPLARI TASARIM DESENLERİ TASARIM ÖRÜNTÜLERİ TASARIM ŞABLONLARI 1

2 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

3 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

4 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

5 GEÇMİŞTEN GÜNÜMÜZE YAZILIM MİMARİLERİ 5

6 Anti Kalıplar (Anti-Patterns) 6

7 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

8 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

9 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

10 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

11 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

12 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

13 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

14 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

15 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

16 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

17 5.God Object (Tanrısal Nesne) 17

18 5.God Object (Tanrısal Nesne) Gereğinden çok şey bilen ve yapabilen sınıflara denmektedir. 18

19 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

20 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

21 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

22 6.Golden Hammer (Altın Çekiç) Söz konusu durumun oluşmasının nedenlerinden birisi, teknolojik gelişmelerden ekiplerin haberdar olmamasıdır. Var olan bir çözüm yerine ondan daha kötü olan özel bir çözüm üretme hatasına düşmektir. 22

23 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

24 GoF (Gang of Four) Sistematiği GoF Kalıpları Creational Patterns Nesne yaratılışına ait Kalıplar Structural Patterns Yapısal Kalıplar Behavioral Patterns Davranışsal Kalıplar 24

25 GoF (Gang of Four) Sistematiği Creational Patterns Nesne yaratılışına ait Kalıplar Kalıplar Abstractfactory Builder Factorymethod Prototype Singleton 25

26 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

27 GoF (Gang of Four) Sistematiği Structural Patterns Yapısal Kalıplar Adapter Bridge Decorator Facade Proxy 27

28 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

29 GoF (Gang of Four) Sistematiği Behavioral (Davranışsal) Kalıplar Chainofresponsibility Command Interpreter Iterator Mediator Memonto Observer State Strategy Visitor 29

30 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

31 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

32 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

33 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

34 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

35 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

36 Factory Method (Fabrika Tasarım Kalıbı) Ancak bazı nesnelerin (Product) kullanıcı(client) olarak erişebileceğimiz başlangıç fonksiyonları bulunmamaktadır. 36

37 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

38 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

39 Factory Method (Fabrika Tasarım Kalıbı) Factory Method sınıf diyagramı 39

40 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 ve factorymethod için bir implementasyon sağlayan sınıf. 40

41 Ö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

42 Örnek: SekilFactory-devam UML sınıf şeması: 42

43 Örnek: SekilFactory-devam 1.İlk olarak ISekil arayüzünü yaratırız. ISekil.java 43

44 Örnek: SekilFactory-devam 2.Sonrasında ISekil arayüzünü implemente eden somut sınıfları yaratırız. Kare.java 44

45 Örnek: SekilFactory-devam 2.Sonrasında ISekil arayüzünü implemente eden somut sınıfları yaratırız. Cember.java 45

46 Örnek: SekilFactory-devam 2.Sonrasında ISekil arayüzünü implemente eden somut sınıfları yaratırız. Dikdortgen.java 46

47 Ö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

48 Örnek: SekilFactory-devam SekilFactory.java ESekilTur.java 48

49 Ö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

50 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

51 Örnek2: ProductFactory 51

52 Örnek2: ProductFactory 1.Iproduct ara yüzünü yaratınız. IProduct.java 52

53 Örnek2: ProductFactory 2.ProductOne somut sınıfını yaratınız. ProductOne.java 53

54 Örnek2: ProductFactory 2.ProductTwo somut sınıfını yaratınız. ProductTwo.java 54

55 Örnek2: ProductFactory 3.ProductFactory sınıfını yaratınız. ProductFactory.java 55

56 Örnek2: ProductFactory 4.Client sınıfını yaratınız. Client.java 56

57 Tasarım Kalıpları II Bu bölümde; FacadeTasarım Kalıbı ile ilgili konular anlatılacaktır. 57

58 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

59 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

60 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

61 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

62 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

63 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

64 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

65 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

66 Facade Cephe/ ÖnYüz Tasarım Kalıbı Örnek: Seyahat Acentesi Seyahat +otelrezervasyonu:otelrezervazyon +ucusrezervasyonu:ucusrezervazyon +UygunOtelveUcusListele(Date seyahatbaslangic,date seyahatbitis):void Program +seyahat:seyahat UcusRezervasyon OtelRezervasyon +gidistarihi:date +donustarihi:date +UygunUcuslariListele(Date gidis,date donus):arraylist<ucus> +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

67 Facade Cephe/ ÖnYüz Tasarım Kalıbı Otel.java Örnek: Seyahat Acentesi 67

68 Facade Cephe/ ÖnYüz Tasarım Kalıbı Ucus.java Örnek: Seyahat Acentesi 68

69 Facade Cephe/ ÖnYüz Tasarım Kalıbı Örnek: Seyahat Acentesi OtelRezervasyon.java 69

70 Facade Cephe/ ÖnYüz Tasarım Kalıbı UcusRezervasyon.java Örnek: Seyahat Acentesi 70

71 Facade Cephe/ ÖnYüz Tasarım Kalıbı Seyahat.java Örnek: Seyahat Acentesi 71

72 Facade Cephe/ ÖnYüz Tasarım Kalıbı Program.java Örnek: Seyahat Acentesi 72

73 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

74 Facade Cephe/ ÖnYüz Tasarım Kalıbı Örnek: SekilCizici UML sınıf diyagramı: Program +sekilcizici:sekilcizici +Ciz():void Kare +Ciz():void <<Interface>> ISekil <<realize>> Cember +Ciz():void SekilCizici -cember:isekil -dikdortgen:isekil -kare:isekil +CemberCiz():void +KareCiz():void +DikdortgenCiz():void +SekilCizici():void Dikdorgen +Ciz():void 74

75 Facade Cephe/ ÖnYüz Tasarım Kalıbı ISekil.java Örnek: SekilCizici 75

76 Facade Cephe/ ÖnYüz Tasarım Kalıbı Kare.java Örnek: SekilCizici 76

77 Facade Cephe/ ÖnYüz Tasarım Kalıbı SekilCizici.java Örnek: SekilCizici 77

78 Facade Cephe/ ÖnYüz Tasarım Kalıbı Program.java Örnek: SekilCizici 78

79 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, Notlarc4b1m.aspx 79