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

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

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

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

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

42. “Sürç-ü lisan ettiysem affola :)”#
!
!
Teşekkür ederim