Design Patterns (Tasarım Kalıpları)

Design Patterns
(Tasarım Kalıpları)
Caner Öncü
[email protected]
Design Patterns Nedir Tam
Olarak?

Ortak dil, ortak problemler, ortak çözümler

Problem... çözüm?
Design Patterns Nedir Tam
Olarak?

Tekerleği yeniden keşfetme!

«İlla bu çözümleri mi kullanmak zorundayım?
Kendim daha iyisini yaparım!»
«Hmm... Bu sefer çok güzel oldu!»
Peki Bu Bilgi Gerçek Hayatta
Ne İşime Yarayacak?

Ortak dilde konuşan ekip = mutlu ekip
*
*
*: Head First Design Patterns
Peki Bu Bilgi Gerçek Hayatta
Ne İşime Yarayacak?

Kod tabanı, daha rahat:


Anlaşılabilir
Güncellenebilir
«Always code as if the guy who ends up maintaining your code will
be a violent psychopath who knows where you live.»
- John F. Woods
Peki...


Kaç tane kalıp var?
«Gang of Four» da kim?
«Tasarım Kalıpları’nda 20 yıllık deneyim, güleryüzlü hizmet!»
Harika, Hemen Kullanmaya
Başlıyorum!

Amaç değil, araç

Ne kazandık, ne kaybettik?

KISS (Keep It Simple Stupid)
*
«Tek sayfalık uygulama için proje yöneticisi Symfony2’de diretince.»
*: devops-tr
Kaç Tip Tasarım Kalıbı var?

Creational


Structural


Yeni objelerin yaratılması
Farklı objelerin birbirleriyle ilişkilendirilerek bir
bütün olması
Behavioral

Objeler arası iletişim kurulması
*
Singleton (Creational)



Yalnızca 1 objeye ihtiyacımız var
Objeye her sınıftan erişebilmemiz lazım
Obje ihtiyacımız olana kadar yaratılmasın
(lazy initialization)
*
Abstract Factory (Creational)



Örneğin, çalıştığı platformdan bağımsız bir
uygulama geliştirmek istiyoruz
Benzer özelliklere sahip objelerimiz var
Benzer objelerin yaratılma mantığını,
objelerin yaratılacağı sınıfları (concrete
class) tek tek belirtmeden, kontrata
(interface) bağlı gruplamak istiyoruz

Sınıf belirtilm... kontrat... kurgu... ne?!?
*
Abstract Factory (Creational)
*
Builder (Creational)


Kompleks yapıda bir objemiz var (Motor
vs. parçalara sahip bir araba veya değişken
içeriğe sahip bir fast-food menüsü gibi)
Objeyi oluşturmak için belli bir sırayı
bozmadan, adım adım işlemlerden
geçmemiz gerekli
*
Builder (Creational)
*
Factory Method (Creational)


Oluşturacağımız objenin tipini önceden
belirtmek istemiyoruz
Oluşturulacak obje factory metodu
içerisinde runtime’da belirlenecek
*
Prototype (Creational)


Bir objenin özelliklerine sahip olan aynı
tipte bir obje daha yaratmak istiyoruz
(milyonlarca insan hücresi gibi)
Yeni objede yapacağımız değişiklikler
orijinal objeye etki etmeyecek (clone)
*
Adapter (Structural)


Birbiriyle uyumsuz/çalışamayan sınıfları
çalışabilir hale getirmek istiyoruz (Obje ->
JSON, XML gibi)
Aslında mevcut sınıf için "Wrapper class"
kullanmış oluyoruz
*
Bridge (Structural)

Birbirinden farklı, birden fazla interface ile
kombinasyon oluşturarak soyutlama
yapmak zorunda kaldık!



Ne demek şimdi bu?!?
Yapılan bu soyutlama birbirleriyle olan
kombinasyonlara göre interface sayısına
bağlı olarak permütasyon şeklinde artıyor
“Soyutlanan yapıyı soyutla” ki interface
çorbası oluşmasın
*
Bridge (Structural)
*
Composite (Structural)

Basit objelerden ve bu basit objeleri
barındıran kompleks objelerden oluşan bir
yapı istiyoruz.

«Her bir klasör içerisinde dosya olabilir ve bu
dosyalar da, kendi içinde dosyalar barındıran
bir klasör olabilir (rekürsif)»
*
Composite (Structural)
*
Decorator (Structural)

Objelere dinamik olarak
yeni sorumluluklar
yükle/becerilerini arttır


«James Bond ve bitmek
bilmeyen özelliğe sahip
silahları gibi»
Sadece metodlar değil,
property’ler de
eklenebilir/düzenlenebilir
«İliğimizi kuruttun 007...»
Decorator (Structural)
Facade (Structural)

Birçok sistemi bir üst
sistemde toplayarak
bu alt sistemlere
erişim kolaylığı sağla

«Uğraşamam ben önce
1’e sonra 4’e sonra 7’ye
basmakla, müşteri
hizmetleriyle görüşmek
istiyorum!»
Facade (Structural)
Flyweight (Structural)


Birbirine benzer çok sayıda obje oluşturmak
istiyoruz
Bunu yaparken de memory’i tüketmek
istemiyoruz
Flyweight (Structural)


Birbirine benzer çok sayıda obje oluşturmak
istiyoruz
Bunu yaparken de memory’i tüketmek
istemiyoruz
Proxy (Structural)


Bol bol kaynak tüketen bir objeye sahibiz
Bu sebeple, objeyi kullanmadan önce initialize
etmek istemiyoruz
Proxy (Structural)


Bol bol kaynak tüketen bir objeye sahibiz
Bu sebeple, objeyi kullanmadan önce initialize
etmek istemiyoruz
Chain of Responsibility
(Behavioral)


Bir istek sonucu oluşacak
etkiyi gerçekleştirecek
yapıların birbirlerine
bağlanmasıyla oluşur
Birçok yapıdan yalnızca
biri yapılacak işi
gerçekleştirir

«ATM’lerde çekilen paraya uygun
banknot’un hazneden verilmesi
gibi»
Chain of Responsibility
(Behavioral)
Command (Behavioral)


Yapılacak bir çağrı için tüm bilgiyi bir
objede tutmak istiyoruz
Alakalı komut istenen zamanda, sıralı
işlemler içeren bir batch şeklinde
çağrılabilir
Interpreter (Behavioral)


Belirli kural kümelerini bir gramerle ifade
etmek istiyoruz
Bu kural kümelerini
anlamlı ifadeye
çeviren bir
tercüman ihtiyacı
duyuyoruz


«Müziğin notayla
ifade edilmesi»
«SQL ifadeleri»
Iterator (Behavioral)


Sırayla dolaşmak istediğimiz biraraya gelmiş
obje kümemiz var
Amacımız yalnızca sırayla dolaşmak (linked list,
hash table gibi), nasıl dolaştığımızın detaylarını
öğrenmek istemiyoruz
Mediator (Behavioral)


Sınıfların birbirleriyle direkt konuşmasını
istemiyoruz ki sınıflar arası dependency
oluşturmak durumunda kalmayalım
Araya aracı
koyarak sınıflar
arası haberleşme
detaylarını
aracıya
aktarıyoruz

«Hava trafik
kontrol» gibi
Memento (Behavioral)

Objenin bir iç
durumuna ait değerler
için «checkpoint»
oluşturmak istiyoruz

Oyun karakterimiz
öldüğünde eşyalarımızı
yitirip sağlık, açlık,
başlangıç noktası gibi
değerlerin «varsayılan»
değerlere dönmesi gibi
«Her gün aynı şey, canımdan bezdim...»
- Guy Pierce, Memento
Memento (Behavioral)
Observer (Behavioral)


Bir objeyle alakalı değişim
olduğu zaman, bu
değişimden belirli objeleri
haberdar etmeyi
amaçlıyoruz
Dinamik biçimde bu
değişikliğin takibini yapacak
objeleri ekleyip/çıkartmak
istiyoruz

Açık arttırma görevlisi (subject)
ve açık arttırma katılımcıları
(observer) gibi
Observer (Behavioral)
State (Behavioral)

Objenin davranış biçimini kendine ait olan
belirli durumlara göre dinamik biçimde
değiştirmesini istiyoruz


«State machine» gibi
Play tuşuna bastıktan
sonra tekrar basınca
Pause işlemi
gerçekleşmesi (tersi
biçimde devam etmesi)
gibi
Strategy (Behavioral)


Bir sınıfa ait davranışlar
dinamik olarak
değişebiliyorsa bu
davranışlara ait
algoritmaları ayrıştırarak
saklamamız mantıklı
olacaktır
Böylece runtime’da
davranışları karışıklık
yaşamadan değiştirebilir
hale geleceğiz
Strategy (Behavioral)
Template Method (Behavioral)

Bir sınıfa ait birbirine
benzer yapıya sahip
algoritmalarda
yalnızca bazı
adımları değiştirmek
istiyoruz
Visitor (Behavioral)



Sınıflarımıza yeni bir metot eklemek istiyoruz
Eklenmesi gereken sınıflara tek tek manuel
biçimde ekleyip kod bakımını zorlaştırmak
istemiyoruz (güncelleme gerektiğinde her yeri
güncellemek gerekecek)
Birden fazla sınıfın implement ettiği interface’e
ekleyip tek tek sınıflarda implementasyonunu
da gerçekleştirmek istemiyoruz
Visitor (Behavioral)
Teşekkürler!

Dilerseniz bu sunumun kopyasına
http://koddit.com/design-patterns
adresinden ulaşabilirsiniz!
Kaynakça










Head First Design Patterns, O’Reilly Media
Gang of Four, Design Patterns
http://sourcemaking.com/design_patterns
http://www.codeproject.com/Articles/430590/Design-Patterns-ofCreational-Design-Patterns
http://www.codeproject.com/Articles/438922/Design-Patterns-ofStructural-Design-Patterns
http://www.codeproject.com/Articles/455228/Design-Patterns-ofBehavioral-Design-Patterns
http://www.tutorialspoint.com/design_pattern/
http://www.dofactory.com/net/design-patterns
http://wwwswt.informatik.unirostock.de/deutsch/Lehre/Uebung/Beispiele/PatternExamples/pate
xamples.htm
http://devops-tr.tumblr.com