Design Patterns (Tasarım Kalıpları)

Design Patterns (Tasarım Kalıpları) Caner Öncü caner@koddit.com

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 Yeni objelerin yaratılması Structural 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-of- Creational-Design-Patterns http://www.codeproject.com/articles/438922/design-patterns-of- Structural-Design-Patterns http://www.codeproject.com/articles/455228/design-patterns-of- Behavioral-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