Ankara JUG Şubat 2014 Etkinliği - Design Patterns
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Ankara JUG Şubat 2014 Etkinliği - Design Patterns

on

  • 328 views

Akın Kaldıroğlu tarafından Ankara JUG Şubat 2014 etkinliğinde gerçekleştirilen Design Patterns konulu sunum dokümanıdır.

Akın Kaldıroğlu tarafından Ankara JUG Şubat 2014 etkinliğinde gerçekleştirilen Design Patterns konulu sunum dokümanıdır.

Statistics

Views

Total Views
328
Views on SlideShare
328
Embed Views
0

Actions

Likes
0
Downloads
6
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Ankara JUG Şubat 2014 Etkinliği - Design Patterns Presentation Transcript

  • 1. Tasarım Şablonları" (Design Patterns) Akın Kaldıroğlu" akin@javaturk.org Ankara Java User Group Konuşması 27 Şubat 2014
  • 2. Gündem • Yazılımın Doğası • • • • Karmaşıklık ve Değişim Sistem Prensipleri a .j Tasarım Şablonları w w Örnek Şablonw a v r u t www.javaturk.org g r .o k $2
  • 3. Yazılımın Doğası • g r .o Yazılımın en temel iki özelliği, karmaşıklık k r (complexity) ve değişmedir (change). u t a v a solution for constructing The most radical possible .j software is not to construct it at all. w w w ! F. Brooks in No Silver Bullet www.javaturk.org $3
  • 4. Yazılım Karmaşıktır - I • g r pek çok bilime Yazılımın, diğer mühendisliklere hatta o .edilmektedir, göre daha karmaşık olduğu iddia k r çünkü yazılım u t a yoktur, Soyuttur, zihinseldir, fiziksel kısıtları v a .j ve kavranması zordur, Görünmez, düşünülmesi w wyoktur, her yazılımı diğerlerinden ayıran Çoğunlukla örneği w vardır, pek çok temel özellik • • • www.javaturk.org $4
  • 5. Yazılım Karmaşıktır - II • g r .o k Yazılım sisteminin durumlarının sayısı çok fazladır, • • • Her yönüyle tanımlamak, tasarlamak ve test etmek imkansızdır, Yazılım yaşam döngüsünde belki en kolayı, yazılımı kodlamaktır. a v Yazılımların bileşenleri birbirlerinden farklıdır, birbirlerine benzeyen kısımlar zaten birleştirilir, a .j w w Yazılımların bileşenleri arasındaki ilişkiler de lineer değildir, w • • • r u t Dolayısıyla yazılımların büyümesi var olan bileşenlerin büyümesiyle değil de yeni ve orijinal bileşenlerin eklenmesiyle gerçekleşir. Nihayetinde tüm bunlar iletişim zorluğuna sebep olur. www.javaturk.org $5
  • 6. Kulaktan Kulağa a .j w w w a v r u t www.javaturk.org g r .o k $6
  • 7. Sistem Teorisi Açısından • g r .o k Yazılımın karmaşıklığının en temel üç faktörü şunlardır: • • • r u t Program parçalarının karmaşıklığı: nesneler, metotları ve aralarındaki ilişkiler a v a .j w w w Veriler ve bilgi karmaşıklığı: İşlenen veri yapılarının durumları Program girdileri ve çıktıları arasındaki kamaşıklık: Girilen veriler ve eventler ile üretilen hizmetler, GUI yapıları, nesne, veri, rapor, vs. arasındaki yapı, dönüşüm ve işlemlerle ilgili karmaşıklık ile sahip olunması gereken bilginin karmaşıklığı www.javaturk.org $7
  • 8. Wood’s Task Complexity a .j w w w a v r u t www.javaturk.org g r .o k $8
  • 9. Toplam Karmaşıklık • g r Bileşen Karmaşıklığı = Program o parçalarının . karmaşıklığı + Veri/bilgi karmaşıklığı" k r u t a v a = Program girdileri ve Koordinasyon Karmaşıklığı .j w çıktıları arasındaki kamaşıklık" w w Bu iki karmaşıklık size neyi çağrıştırıyor? ! • • www.javaturk.org $9
  • 10. Birliktelik - Cohesion • g Bileşen karmaşıklığı, bileşenin alt parçalarının ne r .o kadar “birlikte” olduğunun bir ölçüsüdür, k r olmalı u Nesneler, “efradını cami ağyarını mani” t a v Birliktelik tek bir amaca odaklılıktır (cohesion) ve birlikteliği a düşüktür, yüksek bileşenlerin karmaşıklığı .j w Birlikteliği düşük sistemlerin bakımı daha zordur. " w w High-cohesion • • • • www.javaturk.org $10
  • 11. Bağımlılık - Copuling • g kendi r kadar Koordinasyon karmaşıklığı, bir işin o ne .diğerleriyle ne başına ifade edilebilirliğinin ya da k r kadar “ilgili” olduğunun ölçüsüdür, u t a ve bağımlılığı düşük olan İlgililik, bağımlılıktır (coupling) vdüşüktür, bileşenlerin karmaşıklığıja da . w Bağımlılığı yüksek sistemlerin bakımı da zordur." w w Low-coupling • • • www.javaturk.org $11
  • 12. Ne Kadar Bağımlılık? a .j w w w a v r u t www.javaturk.org g r .o k $12
  • 13. Yazılım Sürekli Değişir - I • • • g r Değişmek, yazılımın doğasının bir parçasıdır, herkes .o k yazılımda değişmeyecek bir kısım olmadığında r u hemfikirdir, t a v Diğer mühendislik ürünlerinde değişimin temel sebebi, a aşınma ve bozulmadır, j . w w Yazılımda ise değişimin temel sebebi, yeni ihtiyaçlardır, w Bakım, büyük oranda değiştirmekdir, • • Yeni ihtiyaçlar, yazılımın bileşen ve koordinasyon karmaşıklığını arttırır. www.javaturk.org $13
  • 14. Yazılım Sürekli Değişir - II • • g yazılımlar r Diğer mühendisliklerin aksine, başarısız o .başarısızdırlar, çoğu zaman değişemedikleri için k r başarılı yazılımlar ise değişenlerdir. u t a Yazılımın değişmesi çok v maliyetlidir, çünkü eklenen a yep-yeni bir parçadır ve var olan bileşenlerle ilişkisi .j yani koordinasyon lineer olarak düzenlenemez w bir şekilde katkıda bulunur. karmaşıklığına non-linear w w Design for change • www.javaturk.org $14
  • 15. Kendini Bilmek • • • Dolayısıyla daha kolay yönetilen ve değişen yazılımlar için birlikteliği yüksek, bağımlılığı düşük sistemler üretmeliyiz, g r .o kadar çok ve Bir sistemin parçaları kendi hakklarında ne kbilir ise o kadar iyidir. r başka parçalar hakkında ne kadar az u t Kendini bil, dedikodu yapma! a v a .j w w w • Highly-cohesive, lowly coupled:# • Know yourself# • Single responsibility principle# • Principle of least information (Law of Demeter, LoD) www.javaturk.org $15
  • 16. En Az Bilgi Prensipi - I • • Law of Demeter, En Az Bilgi Prensipi (Principle of Least Knowledge) olarak da bilinir, g r o .kendisi üzerinde Buna göre bir nesnenin metotlarında, k r ancak şunlar olabilir: metot çağrısı yapabileceği nesneler u t a O nesnenin instance variableları, v a nesneler, .j O nesnenin metotlarına geçilen w w O nesnenin o metotunda oluşturulan nesneler. w • • • • Yani bir nesne ancak arkadaşlarıyla konuşur, yabancılarla konuşmaz. www.javaturk.org $16
  • 17. En Az Bilgi Prensipi - II g r .o k  public  class  A{   !   private  B  b;         public  void  f(C  c){           b.g();     //  Yapılabilir       c.u();     //  Yapılabilir             D  d  =  c.v();    //  Yapma  bunu!!!       d.w();          //  D'den  iş  isteme,  C'den  D'den  iş                                          //  istemesini  iste.     }   } a .j w w w a v r u t www.javaturk.org $17
  • 18. Prosedürel Paradigma - I • • • g r Prosedürel (procedural, imperative) paradigmanın en o .kavramına sahip temel problemi sağlıklı bir “kendi” k r olmayışıdır. u t a edebilmek için gerekli v Bir soyutlamayı düzgün ifade a yapılara sahip değildir, .j w w Kendini sadece metot/fonksiyon seviyesinde ifade w edebilir. www.javaturk.org $18
  • 19. Prosedürel Paradigma - II • g r .o k Bundan dolayı procedürel yapılar, kendini ya da kendi sorumluluğunu bilmek yerine, bir görevle ilgili her sorumluluğu bilmeye çalışır. r Dolayısıyla sorumluluk yerine fonksiyonelliğe odaklanır. u t a yüksek bağımlılık Çok fazla bilgi => Düşük birliktelik, v a .j ilgili değişimi sadece metot Ayrıca bir soyutlama ile w çoğu zaman mümkün değildir, seviyesinde yönetmek w w birden fazla metot ve veri yapılari Değişim çoğunlukla • • • • etkiler www.javaturk.org $19
  • 20. “Kendilik” Soyutlamaları raw lines of code Level%0 the procedural module a .j w w w %Level%1 a v r u t g r .o k the class / object structure %%%%%%%%Level%2% 16 www.javaturk.org $20
  • 21. Düşük ve Yüksek Birliktelik a .j w w w a v r u t www.javaturk.org g r .o k $21
  • 22. Cohesion & Coupling • g r .o k Sonsuz cohesion mümkün olamayacağı gibi sıfır coupling de mümkün değildir. a .j w w w a v r u t www.javaturk.org $22
  • 23. Bağımlılık Çeşitleri a .j w w w a v r u t www.javaturk.org g r .o k $23
  • 24. Soyut Bağımlılık a .j w w w a v r u t www.javaturk.org g r .o k $24
  • 25. Düşük Bağımlılık • Dolayısıyla en basit ve az bağımlılık, arayüz (interface coupling) ya da mesaj bağımlılığıdır (message coupling). g r .o Program to an interface, not an implementation# k r u sadece hizmet alırlar, Nesneler birbirlerinden bilgi almazlar, t a v olsa aynı soyutlamayla ilgili Bir nesnenin varlık sebebia olsa .j olamaz. sorumluluklar olabilir, veri w Bilgi, bir nesnenin w sorumluluklarını yerine getirmek içın w ihtiyaç duyacağı en önemli şeydir. • • • • • Responsibility-driven design www.javaturk.org $25
  • 26. Date Hakkında - I public  class  Date  {     private  int  day;     private  String  month;     private  int  year;   ! • Date sınıfını, birliktelik ve bağımlılık açısından ele alalım. • • Nedir sizce bu nesnenin birlikteliği? a .j w Ve diğer nesnelerle olan w ya da olacak olan irtibatı, w bağımlılığı nedir? a v g r .o k       public  int  getDay()  {     return  day;   }         public  void  setDay(int  day)  {     this.day  =  day;   }         public  String  getMonth()  {     return  month;   }         public  void  setMonth(String  month)  {     this.month  =  month;   }         public  int  getYear()  {     return  year;   }         public  void  setYear(int  year)  {     this.year  =  year;   }   ! r u t ! ! ! ! !   public  String  toString()  {       return  "Date:  "  +  day  +  "  -­‐  "  +                                  month  +  "  -­‐  "  +  year;     }   } www.javaturk.org $26
  • 27. Date Hakkında - II • g r .o yerine getirebilir? Fakat tarih kavramıyla ilgili hangi hizmetleri k r u sahip, tbilgiye Gerçekte Date, tarih ile ilgili a v sorumluluklara sahip değil, a .jbir hizmet vermiyor. Sadece veri taşıyor, w hiç w w Dolayısıyla, üç-beş private değişken ve get/set Date, sadece “tarih” kavramına odaklı, bu güzel. • • • • metotlarıyla nesne-merkezli programlama olmaz! www.javaturk.org $27
  • 28. Date Hakkında - III • • • Date nesnesi birlikteliği son derece düşük, g r olacak, Bu yüzden de bağımlılığı son derece yüksek .o k aşağıdaki tarih ile r Çünkü, örneğin sistemde ihtiyaç duyulan u ilgili sorumlulukları yerine getirmediği için, diğer sınıflar, Date tyıl) bilgisini alarak bu a nesnesinden sadece (gün, ay ve v sorumluluklari kendileri yerine getirmeye çalışacaklar: a .j w w w public Date nextDay(Date date) public String getWeekDay(Date date) ! String print() String print(Locale locale) String print(DateFormat format) String print(Locale locale, DateFormat format) … www.javaturk.org $28
  • 29. Tasarım Şablonu Nedir? I • Tasarım Şablonları, temel nesne-merkezli prensipleri kullanarak • doğru sorumlulukları bulmamıza, • • • a .j w w w highly-cohesive objects nesneleri, aralarında az bağımlılık yaratacak şekilde kurgulamamıza yardımcı olur. • ! a v r u t değişimi göz önüne alarak bu sorumlulukları nesnelere dağıtmamıza, • • Finding responsibilities g r .o k lowly-coupled objects Yüksek birliktelikli ve düşük bağımlılıklı yapıları nasıl kurgulayacağımızı, sıklıkla karşılaşılan problemler bağlamında çözer. www.javaturk.org $29
  • 30. Tasarım Şablonu Nedir? II • a v ! • g r .o k Christopher Alexander says, "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice“ r u t a .j w w Bu anlamda tasarım şablonu, bir bağlamda sıklıkla w karşılaşılan yazılım tasarımı problemine genel ve tekrar kullanılabilen (reusable) bir çözümdür. www.javaturk.org $30
  • 31. Tekrarlanan Problemler • Nesneleri nasıl yaratırız? • Karmaşık nesneleri nasıl yaratırız? g r .o k • r u nasıl tasarlarız? t Nesneler arasındaki bütün-parça ilişkisini a v bunları nasıl ifade ederiz? a Bir işi yapmanın pek çok yolu varsa .j w Emir-komuta ya da olay-bilgilendirme zincirini nasıl oluştururuz? w w Bir nesneye çalışma zamanında yetkinlik nasıl kazandırırız? • Karmaşık duruma sahip olan nesneleri nasıl yönetiriz? • • • • Nesnelere erişimi nasıl kontrol ederiz? www.javaturk.org $31
  • 32. Neden Tasarım Şablonları? • • g r Tasarım şablonları çoğu defa bize,o normalde nesne. merkezli programlama dili kullanmamıza rağmen k r prosedürel anlayışta yazılım geliştirmeye düşmekten u t kaçınmamızı sağlar. a v a bir metot altında pek çok if j Bu yüzden normalde .tek w ile yaptığımız “functional decomposition” tarzındaki w yapıları, nesne seviyesinde nasıl ifade edeceğimizi w bize öğretir. www.javaturk.org $32
  • 33. Farklı Tipte Şablonlar • • g problemler r Tasarım şablonları nesne seviyesindeki .o içindir, iş alanından bağımsızdır.k r u patterns) t Mimari şablonlar (Architectural a v patterns) a Güvenlik şablonları (Security .j w Performanş şablonları (Performance patterns) w w (Business domain patterns) İş Alanı Şablonları • • • www.javaturk.org $33
  • 34. Şablonun Bileşenleri !Item! Description! Name% All%patterns%have%a%unique%name%that%identifies%them.% Intent% The%purpose%of%the%pattern.% Problem/Motivation% The%problem%that%the%pattern%is%trying%to%solve.% Solution/Structure% How%the%pattern%provides%a%solution%to%the%problem%in%the%context%in% which%it%shows%up.% Participants%and%collaborators% The%entities%involved%in%the%pattern.% Consequences% The%consequences%of%using%the%pattern.%Investigates%the%forces%at%play%in% the%pattern.% Implementation% How%the%pattern%can%be%implemented.% Note:%Implementations%are%just%concrete%manifestations%of%the%pattern% and%should%not%be%construed%as%the%pattern%itself.% Generic%Structure% A%standard%diagram%that%shows%a%typical%structure%for%the%pattern.% Applicability% What%are%the%situations%in%which%the%design%pattern%can%be%applied?% Sample%code% Code%fragments%that%illustrate%the%pattern%in%a%objectJoriented%language% Known%uses% Examples%of%the%pattern%found%in%real%systems% Related%patterns% What%design%patterns%are%closely%related%to%this%one?%What%are%the% important%differences?%
  • 35. Neden Tasarım Şablonları? • • • g r .o Tekerleği yeniden keşfetmemek, var olan ispatlanmış k çözümleri kullanmak, r u t a Formal ve yaygın bir dil oluşturmak, v a .j soyutlama gücü Tasarıma uygun, yüksek w sıyrılıp, daha yüksek kazandımak, detaylardan w düşünmek. hedefler cinsinden w www.javaturk.org $35
  • 36. İlk Çalışmalar • • • • • g r Trygve Reenskaug, Smalltalk’la MVC .o k (Model-View-Controller)! r u t Kent Beck ve Ward Cunningham! a v aDörtlü Çete j 1994 - Gang of Four (GoF) .and Vlissides! Gamma, Helm, Johnson, w ! w ! wMeunier, Rohnert, 1996 - Buschmann, Christopher Alexander! Sommerlad, Stal www.javaturk.org $36
  • 37. Dörtü Çete • g r .o k Dörtlü çete kitapta 3 farklı kategoride toplam 23 tane şablona yer vermişlerdir: • Creational • Structural • Behavioral a .j w w w a v r u t • Okuması tecrübeli olmayanlar için zordur, • Örnekleri C++ ile verilmiştir, • İlk iki bölümü nefis bir OO özetidir. www.javaturk.org $37
  • 38. Bazı Noktalar • • g r .o çetenin bur Unutulmaması gereken şey, bu dörtlü k şablonları yoktan var etmediği r gerçeğidir u t a bir ya da bir kaçıyla Bağlamınızı bu 23 şablondan v a süslemek zorunda değilsiniz. .j w Sizler de size özel bağlamınızda kendinize özel şablonlar w bulabilirsiniz, bulmalısınız. w • www.javaturk.org $39
  • 39. Kaynaklar • • • • • g r .o Shalloway, Trott, Design-Patterns Explained k r u Patterns t Design E. Freeman et al., Head-First a v a M. Page-Jones, Fundamentals of Object-Oriented .j Design in UML w w w Özcan Acar, Java Tasarım Şablonları ve Yazılım F. Brooks, Mythical-Man Month & No Silver Bullet Mimarileri www.javaturk.org $40
  • 40. Örnek: Proxy Pattern • Aşağıdaki problemi GoF’un Proxy tasarım şablonu ile nasıl çözeceğimizi görelim: • • • • g r .oyönetenlere ulaşma Demokrasilerde vatandaşların kendilerini k r hakları vardır, u t a olarak vatandaşlar dinleme Başbakan’ın da en tepe yönetici v zorunluluğu vardır, a .j Ama Başbakan’ın 75w milyon kişiyle görüşmesi hem imkansızdır w hem de uygun değildir, w Bu durumda vatandaşların Başbakan’la görüşme haklarını nasıl yönetiriz? www.javaturk.org $41
  • 41. “Sürç-ü lisan ettiysem affola :)”# ! ! Teşekkür ederim