Design Patterns TASARIM ÖRÜNTÜLERİ ebru@hacettepe.edu.tr ebruakcapinarsezer@gmail.com @ebru176 2014,15

Uzun uzun yıllar önce….. Christopher Alexender, mimari ürünlerin (yapıların) gerçekleştiriminde tasarımın kalitesini ölçeklendirme ve tasarım kalitesinin ürün üzerindeki etkisi üzerine çalışmış bir mimardır Tasarım kalitesi üzerinde yaptığı çalışmalarda tekrar tekrar karşılaşılan ve benzer çözümlere sahip olan durumlar ile karşılaşmış. Ve tasarım örüntüsü olarak adlandırmış.

Örüntüyü babası tanımlıyor Alexander’ın örüntü (pattern) tanımı “Each pattern describes a problem 1)which occurs over and over again in our environment and then 2)describes the core of the solution to that problem, in such a way that 3)you can use this solution a million times over, without ever doing it the same way twice”

Tasarım Örüntüsü Özetle tasarım örüntüsü aynı probleme ait aynıya yakın çözümdür İlk bir mimar tarafından kullanılmıştır [Alexander]

Alexander için örüntü bileşenleri Örüntünün bir adı vardır Örüntünün kullanım amacı yani çözdüğü bir problem vardır Örüntüyü uygulama biçimi, yolu vardır Örüntüyü uygulamak için uyulacak kısıtlar ve zorlamalar vardır Örüntüler bir tasarımda birbirleri ile birlikte karmaşık mimari tasarımları oluşturmak için kullanılabilir.

Mimari Tasarım -> Yazılım Tasarımı 1990 başlarında Alexander’ın mimari örüntüleri yazılım tasarımında da örüntüler için tartışmayı başlattı Yazılımda da tekrarlı oluşan ve aynı yöntemle ele alınan tasarım problemleri var mı ? Yazılımı örüntüleri kullanarak, özel sorunları örüntülere dayandırarak tasarlamak mümkün mü Bu iki soruya derhal evet diyen “desing patterns: elements of reusable object oriented software (1995)” kitabının yazarlarıdır: gamma, helm, johnson ve vlissides (nam-ı diğer gang of four).

GoF’un kitabı önemlidir. Yazılıma ait örüntü kavramını oluşturmuş ve “design patterns” adı verilmiştir. 23 tane örüntü için problem, amaç ve çözüm bilgileri içeren ciddi bir katalogdur Nesneye yönelik tasarımı örüntü temellerine oturtarak yeniden gözden geçirmişlerdir.

Bir Örüntü için temel özellikler Adı(Name) Niyeti(Intent) Problem Çözüm(Solution) Sonuçları(Consequencies) Gerçekleştirim (Implementation) Üreysel Yapısı(Generic Structure)

Neden GoF’u ciddiye aldık ? Yeniden kullanılabilinir çözüm fikrini önermişlerdir: Önceki tecrübenin aktarımını sağlayan, güvenilirliği sınanmış çözümler her zaman iyi fikirdir Ortak terminolojinin oluşumunda katkıları büyüktür: projenin analiz ve tasarımında örüntü adları ortak referans olup, az konuşup çok şey söylemeyi sağlar Problemi örüntü tabanlı incelemek nesneye yönelik tasarımda üst düzey öngörüyü oluşturur Tasarım örüntüleri ile daha kolay değiştirilen ve bakımı yapılan kodlar ortaya çıkar (tecrübe göstermiştir)

GoF’un temel stratejileri 23 adet örüntüde GoF’un temel önerisi şu olmuştur: “Design interfaces” “Favour aggregation over inheritance” “Find what varies and encapsulate it”

Örüntü Listesi Abstract Factory Builder Prototype Singleton etc. Oluşturucu (Creational) Yapısal (Structural) Davranışsal (Behavioral) Abstract Factory Builder Prototype Singleton etc. Adapter Bridge Composite Decorator Facade Proxy Command Iterator Observer Strategy Interpreter Mediator

Design Patterns (Creational) Oluşturucu örüntüler, yaratım (instantiation) işlemini soyutlarlar. Sistemin, nesnelerinin yaratımını(create), birleştirimlerinde (composed) ve kullanımlarından bağımsızlaşmasına yardımcı olurlar. (Factory, Singleton)

Design Patterns (Structural) Yapısal örüntüler, sınıfların ve nesnelerin daha büyük ve karmaşık bir yapıyı oluşturmak için nasıl ele alınmaları gerektiğini gösteren yardımcılardır. (i.e. Inheritance)

Design Patterns (Behavioral) Davranışsal örüntüler, nesneler arası iletişimi gözeterek nesnelere sorumlulukların atanması ve nesnelerin yer aldığı algoritmalar ile ilgilenir.

EK:TÖ, ne zaman ve nasıl kullanılır Uygulanan SDLC ne olursa olsun (i.e. RUP, Scrum, XP) ANALİZ MODELİNİN OLUŞTURULMASI ve YAZILIM GEREKSİNİMLERİNİN MODELLENMESİ

EK: Requirements/Glossary Course Registration System Glossary  Version 2.0 Revision History Date Version Description Author 26/Dec/1998 1.0 Draft version Bill Collings 19/Feb/1999 2.0 Moved some of the terms to the Wylie College glossary. Bill Collings Glossary 1.Introduction The glossary contains the working definitions for terms and classes in the Course Registration System. This glossary will be expanded throughout the life of the project. Any definitions not included in this document may be included in the Rational Rose Model. Generic terms used outside this project should be captured in the organizational Glossary. 2. Definitions Alternative course selection A student might choose to register for one or more alternative courses, in case one or more of the primary selections are not available. Billing System Part of the university's Finance System used for processing billing information.

EK:Requirements/Stakeholder Requests This artifact contains any type of requests a stakeholder (customer, end user, marketing person, and so on) might have on the system to be developed. It may also contain references to any type of external sources to which the system must comply.  Although the system analyst is responsible for this artifact, many people will contribute to it: marketing people, end users, customers-anyone who is considered to be a stakeholder to the result of the project.

EK:Requirements/Stakeholder Requests Stakeholder Requests are mainly collected during the inception and elaboration phases, however you should continue to collect them throughout the project's lifecycle for planning enhancements and updates to the product.  A change request tracking tool is useful for collecting and prioritizing these requests.

EK:Requirements/Storyboard A Storyboard is a logical and conceptual description of system functionality for a specific scenario, including the interaction required between the system users and the system. A Storyboard "tells a specific story".  System Analyst Optional. Produced in early Elaboration, during requirements elicitation.

EK:Requirements/Storyboard Po co ? The following people use the Storyboards: system analysts, to explore, clarify, and capture the behavioral interaction envisioned by the user as part of requirements elicitation. user-interface designers, to design the user interface and to build a prototype of the user interface; designers of the classes that provide the user interface functionality; They use this information to understand the system's interfactions with the user, so they can properly design the classes that will implement the user interface; those who design the next version of the system to understand how the system carries out the flow of events; those who test to test the system's features; the manager to plan and follow up the analysis & design work.

EK: Requirements/Software Requirements Specification The Software Requirements Specification (SRS) captures the software requirements for the complete system, or a portion of that system. The Requirements Specifier role specifies and maintains the detailed system requirements. Considered first in the Inception phase, refined in the Elaboration and Construction phases.

EK:Requirements/Software Requirements Specification The following people use the Software Requirements Specification: The system analyst creates and maintains the Vision and Supplementary Specifications, which serves as input to the SRS and are the communication medium between the system analyst, the customer, and other developers. The requirements specifier creates and maintains the individual use case and other components of the SRS package, Designers use the SRS Package as a reference when defining responsibilities, operations, and attributes on classes, and when adjusting classes to the implementation environment. Implementers refer to the SRS Package for input when implementing classes. The Project Manager refers to the SRS Package for input when planning iterations. Testers use the SRS Package as an input to considering what tests will be required.

Analysis Model In Analysis, we analyze and refine the requirements described in the Use Cases in order to achieve a more precise view of the requirements, without being overwhelmed with the details Again, the Analysis Model is still focusing on WHAT we’re going to do, not HOW we’re going to do it (Design Model). But what we’re going to do is drawn from the point of view of the developer, not from the point of view of the customer Whereas Use Cases are described in the language of the customer, the Analysis Model is described in the language of the developer: Boundary Classes Entity Classes Control Classes

Boundary Classes Boundary classes are used in the Analysis Model to model interactions between the system and its actors (users or external systems) Boundary classes are often implemented in some GUI format (dialogs, widgets, beans, etc.) Boundary classes can often be abstractions of external APIs (in the case of an external system actor) Every boundary class must be associated with at least one actor:

Entity Classes Entity classes are used within the Analysis Model to model persistent information Often, entity classes are created from objects within the business object model or domain model

Control Classes The Great Et Cetera Control classes model abstractions that coordinate, sequence, transact, and otherwise control other objects In Smalltalk MVC mechanism, these are controllers Control classes are often encapsulated interactions between other objects, as they handle and coordinate actions and control flows.

İlk örüntü en kolayı: Adapter Pattern GoF’un Adapter pattern’ın amacı “Convert the interface of a class into another interface that the clients expect. Adapter lets classes work together that could not otherwise because of incompatible interfaces” Küçük örnek : mouse adepter’i hatırladınız mı?

Adapter Pattern Varolan bir sınıf arayüzünü istemcinin beklediği arayüze çevirmektir. Adapter ile farklı arayüze sahip olduğu için birlikte çalışamayacak gibi görünen sınıfların birlikte çalışması sağlanırken, sınıfların var olan tanımları üzerinde bir değişiklik gerçekleşmez.

Adapter: Class Model Adapter is based on the delegation form because an Adapter object delegates the command to the targeted command.

Adapter: Sequence Diagram

Financial Application Example

Adapter Problem TextView getExtent() Shape Line PolygonShape BoundingBox() Createmanipulator() Line PolygonShape DrawingEditor text TextShape BoundingBox() Createmanipulator() Return text.getExtent() Return new TextManipulator Another way?

Adapter ve Adaptee arasında delegasyon (delegation) vardır. Nesne Adaptör Client Target Request() Adaptee ExistingRequest() adaptee Adapter Request() Adapter ve Adaptee arasında delegasyon (delegation) vardır. Adapter sınıfının arayüz belirlemesinde arayüz kalıtımı kullanılır. Target ve Adaptee, Adapter’den önce vardır. Target, javada arayüz (interface) olarak kodlanır

Class Adapter (Açıklamalara ingilizce yer verdim) Client Target Request() Adaptee ExistingRequest() adaptee Adapter Request() A class adapter uses multiple inheritance to adapt one interface to another Not as flexible as object adapter – cannot work with multiple adaptees Let adapter to override some of adaptee’s behavior. Object adapter cannot override adaptee’s behavior.

Uygulanabilirlik Adapter pattern’ı kullanma zamanı İhtiyaç duyulan işlemleri yerine getiren ama uygunsuz arayüze sahip bir sınıf varsa İstemciyi ilgilendirmeyen bir sınıfın istemci farketmeksizin kullanımını sağlamak için yeniden kullanılabilinir bir sınıf tanımlamak

Soru SARMALAMA ( ENCAPSULATION ) NEDİR ?

Sizce kaç tip sarmalama var ?

Sarmalama Türleri Encapsulation of data: Sınıfların içindeki veriler tüm kullanıcılar için sarmalanmıştır. Encapsulation of method: Sınıfların içindeki iletiler arayüzde yer alıyorsa gerçekleştirimleri Arayüzde yer almıyorsa varoluşları Sarmalanmıştır Encapsulation of other objects: Circle dışındaki tüm nesneler XXXCircle’ın varlığından habersizdir. Encapsulation of type: Shape’in istemcileri altsınıfları görmezler. (Shape referansının o an hangi tür (type) bir nesneyi gösterdiğini bilmezler) GoF’un encapsulation tabiri özellikle “encapsulation of type” için geçerlidir.

Soru 1 Rectangle kendi verisini saklamış durumda ve ekrana bir çerçeve ile çıkıyor. RectangleSpecialBorder ise aynı diktörgeni ekrana farklı bir çerçeve ile çiziyor Sizce her iki maddede belirtilen durum için yandaki tasarımlar uygun mudur? 2

Her ikisi de kısmen sorunlu Rectangle için söz konusu olabilecek her bir çerçeve türü yeni kalıtım ya da ileti eklentisi mi? Başka şekiller aynı çerçeve türleri ile çizilecekse onlar içinde mi kalıtım ya da ileti (yeniden kullanılabilirlik) SpecialBorder’ın tanımı değişirse tüm şekillerin iletileri ya da altsınıfları değişecek Aynı anda bir kaç çerçeveleme yöntemi kullanılmak istenirse önceki yaklaşımların çözümü nedir ?

Değişen ne ? GoF derki:”Find what is varying and encapsulate it” Problem: Farklı hayvan karakteristikleri modellenecek Her hayvan farklı sayıda bacağa sahip Hayvan nesnesi bu bilgiyi saklamak ve sunmak zorunda Her hayvan farklı türde hareket yeteneğine (belki yeteneklerine) sahip Her hayvan nesnesi bir noktadan diğerine gitmek için kendi hareket tipine göre ne kadar süreceğini bilmek zorunda Modelinizi sununuz

Değişen hareket türü

Strategy Pattern “Design with change in mind” ...GoF.. Değişikliklerin olabileceği noktaları doğru tespit etmek gerekir Bu yaklaşımın temelleri (GoF’un kitabından) Program to inteface, not an implementation Favor object aggregation over class inheritance Consider what should be vairable in your design Nelerin değişikliğe sebep olabileceği değil yeniden tasarım yapmadan (redesign) neleri değiştirebilmek istediğimiz tespit edilmeli

Problem Bir firmanın uluslar arası e-satış sistemi için sipariş işleme gereksinimi karşılanacak. Bu sistem ile farklı ülkelerden sipariş alınacağı için değişiklik beklenen nokta vergilendirme, teslim tarihi ve teslimat maliyeti farklılıkları içermesidir.

Yeni gereksinim Beklenen değişiklik gerçekleşiyor ve Türkiye, Almanya ve Kanada’dan verilecek siparişler için farklı vergilendirme usülleri uygulanacak Bu değişiklikler için ilk akla gelenler Copy-paste Switch-if Inheritance

If – Switch çözümü Siparişin calcTax()’i içinde //handle tax switch (myNation) { TR: //Handle TR tax rules GER: //Handle GER tax rules CND: //Handle CND tax rules }

Kalıtımla Çözüm Sizce beklenen potansiyel bir sorun var mı ?

Sorun Eğer tek değişebilecek olan vergilendirme usulleri olsa kalıtım kısmen sarmalamayı destekleyebilmektedir. Ancak teslim tarihi de değişecekse ve bu değişiklik vergi değişikliği ile paralel değilse Vergi usulü ülkeden ülkeye değişiyor ama teslim tarihi kıtadan kıtaya değişiyor

Temel prensiplere bir bakış “Find what varies and encapsulate it in a class of its own” “Contain this class in another class”

GoF’un Strateji Pattern özeti Amaç: “Define a family of algorithms, encapsulate each one and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it” Problem: “The selection of an algorithm that needs to be applied depends on the client making the request or the data being acted on. If you just have a rule in place that does not change, you do not need a Strategy pattern”

Devam... Çözüm: “Seperates the selection of algorithm from the implementation of the algorithm. Allows for the selection to be made based upon context” Sonuçları: Defines a family of algorithm Switches/if’s are eliminated You must invoke all algorithms in the same way (They must all have the same interface)

Generic Structure for Strategy

Strategy Pattern değerlendirmesi Encpsulating bussiness rules Lower cost of unit test : Strategy kısmı kendi başına sınanabilir Sorular 1. GoF’un 3 temel prensibi nedir ? 2. GoF’un önerisi: “Consider what should be variable in your design” yaklaşımı Yeniden tasarım sebeplerine yoğunlaşmaktan neden farklıdır ?

DECORATOR PATTERN

Decorator Pattern Decorator pattern yapısal bir tasarım örüntüsüdür. (structural design pattern) Nesnelerin ve sınıfların daha büyük yapıları oluşturmak için nasıl ele alınacağı yapısal tasarım örüntülerinin ilgi alanıdır.

Amaç – GoF der ki : “Attach additional responsibilities to an object dynamically” “A flexible alternative to subclassing for extending functionality” “Also Known As Wrapper” Sarmalayan = > ambalaj kağıdı gibi ( ama şeffaf !!! )

Structure of Decorator Pattern Decorator Pattern İçin Genel Yapı

Nelerden Oluşur ? Component ( Bileşen ) defines the interface for objects that can have responsibilities added to them dynamically. ConcreteComponent ( Somut Bileşen ) defines an object to which additional responsibilities can be attached. Decorator maintains a reference to a Component object and defines an interface that conforms to Component's interface. ConcreteDecorator adds responsibilities to the component.

Problem Pizzanız neli olsun ? Çok malzeme seçeneği var ! sosis, mısır, salam, biber, vb. Her müşteri farklı malzemeden farklı porsiyonda isteyebilir. mısırlı, salamlı ve biberli ama biberi bol olsun ! ( Yani 2 porsiyon biber malzemesi konacak )

1. Çözüm Her olası pizza malzemesi seçimi için bir sınıf yarat !

Java kodu – Tasarımı Eleştiriniz public class Mc { public static void main(String[] args) { MısırlıPz msrPiz = new MisirliPz(); MısırlıZeytinliPz msrZeyPiz = new MisirliZeytinliPz(); MısırlıZeytinliSalamliPz msrZeySalPiz = new MisirliZeytinliSalamliPz(); } public abstract class Pizza { public abstract double cost(); } public class MısırlıPz extends Pizza{ public double cost(){ return 0.8; public class MısırlıZeytinliPz extends Pizza{ return 1.4; public class MısırlıZeytinliSalamlıPz extends Pizza{ return 2.1; ...

Neden Uygun Değil ? Sınıf sayısı fazla Kodda değişiklik yapmak zor zeytinin fiyatı değişirse içinde zeytin olan bütn sınıflar değişecek

2. Çözüm – Tasarımı Eleştiriniz

3. Çözüm Pizza malzemelerinin her birini Decorator Pattern’daki decorator olarak düşün. Component ConcreteComponent Decorator ConcreteDecorator

Java Kodu public class Misirli extends MalzemeliPizza{ protected Pizza pizza; public Misirli (Pizza pizza){ this.pizza = pizza; } public double cost(){ return 1.8 + pizza.cost(); public classDominosPizza{ Pizza pizza = new SadePizza(); Sop( pizza.cost() ); Pizza pizza2 = new SadePizza(); pizza2 = new Salamli( pizza2 ); pizza2 = new Zeytinli( pizza2 ); pizza2 = new Misirli ( pizza2 ); Sop( pizza2.cost() ); Pizza pizza3 = new SadePizza(); pizza3 = Salamli( pizza3 ); pizza3 = Misirli( pizza3 ); public abstract class Pizza { public abstract double cost(); } public abstract class MalzemeliPizza extends Pizza{ /*...*/} public class SadePizza extends Pizza{ public double cost(){ return 1.5;}} public class Salamli extends MalzemeliPizza{ protected Pizza pizza; public Salamli(Pizza pizza){ this.pizza = pizza; return 2.6 + pizza.cost();}} public class Zeytinli extends MalzemeliPizza{ public Zeytinli(Pizza pizza){ this.pizza = pizza;} return 1.3 + pizza.cost();}} * Sop => System.out.println

Değerlendirme public class YeniMalzeme extends MalzemeliPizza{... Diğer çözüme göre daha az sayıda sınıf Malzeme ekleme/çıkarma daha kolay public class YeniMalzeme extends MalzemeliPizza{... Pizzada her çeşit malzeme bir arada bulunabilir. Her ne kadar sadece malzemeler tekil tanımlanmış ise de...

Java I/O 11101111010101010110111111 LineNumberInputStream BuffreredInputStream FileInputStream 11101111010101010110111111

+ lar ve - ler Bu örüntünün 2 artısı ve 2 eksisi vardır : , More flexibility than static inheritance. Statik kalıtımla nesnelere eklenen yetenekler (davranışlar), bu örüntü ile çalışma zamanında (yeni yetenekler eklenerek/çıkartılarak) çok daha esnek bir şekilde yapılabilir.

+ lar ve - ler 2 . Avoids feature-laden* classes high up in the hierarchy. Sınıflara yeni yetenekler eklenirken kullandığın kadar öde ( pay-as-you-go ) mantığıyla hareket edilir. Böylece bütün olası özellikleri destekleyebilecek karmaşık ( complex ) ve özelleşmiş ( customizable ) bir sınıf yerine, daha basit bir sınıf tanımlar ve Decorator nesneleriyle yeni yetenekler ekleriz. * lade : yüklemek

+ lar ve - ler 3 . A decorator and its component aren't identical. 4 . Lots of little objects.

Ne Zaman Kullanmalı Diğer nesneleri etkilemeden, her nesneye yeni yetenekler eklemek ama bunu dinamik ve aynı arayüz ile yapmak için... çıkartılabilir/eklenebilir yetenekler için... Her yeni ekleme için altsınıf yapmak pratik değilse...

Decorator Pattern Problem - 2 Header ve footer lar farklı türde ise ve farklı sayıda tetiklenmesi gerekiyorsa : Header1 Header2 Ticket Footer1 Header Ticket Footer Header2 Header1 Ticket Footer2

Decorator Çözüm

Java Kesiti abstract public class Component { abstract public void prtTicket(); } public class SalesTicket extends Component { public void prtTicket() { /* sales ticket yazdırma kodlarına yer ver*/ } abstract public class TicketDecorator extends Component { private Component myTrailer; public TicketDeorater(Component myComponent) {myTrailer = myComponent} public void callTrailer() { if (myTrailer !=null) myTrailer.prtTicket();} public class Header1 extends TicketDecorator{ public Header1(Component myComponent) { super(myComponent) } public void prtTicket() { // Header1 yazdırma kodlarına yer ver super.callTrailer();

Java Kesiti - Devam public class Header2 extends TicketDecorator{ public Header2(Component myComponent) { super(myComponent) } public void prtTicket() { // Header2 yazdırma kodlarına yer ver super.callTrailer(); } public class Footer1 extends TicketDecorator{ public Footer1(Component myComponent) { super(myComponent) } // Footer1 yazdırma kodlarına yer ver public classFooter2 extends TicketDecorator{ public Footer2(Component myComponent) { super(myComponent) } // Footer2 yazdırma kodlarına yer ver

Örnek çıktılar için kullanımlar HEADER1 HEADER2 SALESTİCKET FOOTER1 HEADER1 SALESTİCKET FOOTER1 Örnek nesne yaratımları return (new Header1( new Footer1 (newSalesTicket()))) return(new Header1 (new Header2 (new Footer1(new SalesTicket()))))

Observer Pattern (Also known as: Publish Subscribe, Listener ) esezer, 2008, Günleme

TANIM Bir nesnenin durumunun gözlemlenmesi ve bu nesnedeki değişikliğin, nesne ile ilgilenen diğer nesnelere iletilmesini sağlayan tasarım örüntüsüdür. Bu amaçla değişiklikleri takip etmek isteyen nesneler bir şekilde değişikliğe uğrayacak nesneye kendilerini kayıt ettirirler veya o nesne hakkındaki değişikliklerden haberdar olurlar

Bir sistemi işbirliği içindeki sınıflara ayırırken ilişkili nesneler arasındaki tutarlılık sağlanmalıdır. Tutarlılığı, sınıfları birbirine sıkı sıkıya bağlayarak sağlamak istenmez, çünkü bu durum tekrar kullanılabilirliği azaltır. Gözleyen nesnenin sorumluluğuda gözlenen nesneye verilemez

Nerelerde Kullanılır Bir nesnedeki değişiklik başka nesnelerde otomatik olarak değişiklik gerektiriyorsa Bir nesnenin başka nesneleri kim olduklarına bakmaksızın bir durumdan haberdar etmeleri gerektiğinde

İlk alıştırma Örneğin birçok GUI aracı kullanıcı arayüzündeki ekran görüntüsünü, bunları oluşturan datalardan ayırır. Kullanıcı arayüzü ile datalar birbirinden bağımsız kullanılabilmelidir, elbette bunlar bir arada da kullanılabilir olmalıdır. Hesap tablosu ya da çubuk grafik oluşturan nesne aynı verileri kullanarak farklı sunuşları yaparlar. Hesap tablosu ya da çubuk grafik birbirlerinin varlığını bilmezler fakat bunlardan ihtiyaca göre herhangi birisi diğerinden bağımsız tekrar kullanılabilir.

İlk Açıklama Buradaki anahtar nesneler SUBJECT ve OBSERVER’dır. Bir subject’e bağlı birçok observer olabilir. Subject nesnesinin durumunda bir değişiklik olduğunda bütün observer nesneleri bundan haberdar olur. Bunun sonucunda da bütün observer nesneleri durumlarını subject nesnesinin durumuyla senkronize etmek isterler. Bu tür bir etkileşim ayrıca PUBLISH-SUBSCRIBE olarak da bilinir. Subject bildirilerin yayınlayıcısıdır. Bu bildirileri, kendisinin izleyicilerinin kimler olduğunu umursamaksızın yayınlar. Herhangi bir sayıdaki izleyici bu bildirileri almayı kabul etmiş sayılır.

Observer Pattern Structure

SUBJECT Kendi gözlemcisini (observer) bilir(??) Herhangi bir sayıda observer nesne bir subject’i izleyebilir. Observer nesnelerini ekleyebilmek ve ayırabilmek için bir arayüz sağlamalıdır.

OBSERVER Güncelleştirme haberini çok biçimli verebilmek için tanımlanmış bir arayüz.

ConcreteSubject ConcreteObserver nesnelerince durumu takip edilir İzlenen nesnedir Durum değişikliklerinde bu değişimi bildirmekle yükümlüdür

ConcreteObserver Gözlemleyen nesnedir. Subject ile tutarlı kalması için gereken güncellemeleri bilir

DAHA FAZLA BİLGİ Subject ve Observer Arasındaki Soyut Birleştirme: Subject’in bildiği tek şey observer’ların bir listesidir ve bu observer’ların her biri soyut Observer sınıfındaki basit arayüze uyarlar. Subject herhangi bir observer’ın somut sınıfını bilmez. Bu nedenle subject ve observer arasındaki birleştirme soyut ve minimaldir.

DAHA FAZLA BİLGİ Genele Yayın Haberleşme İçin Destek: Alışılagelmişin dışında Subject’in yaptığı bildirilerin bir alıcıya özel olması gerekmez. Genele yayın, bu yayını alan bütün nesnelere otomatik olarak gider. Subject kaç tane observer olduğu ile ilgilenmez, subject’in tek sorumluluğu bildiriyi yapmaktır. Bu da herhangi bir zamanda observer ekleme ya da çıkarma özgürlüğü verir. Observer bir bildiriyi alacağına ya da reddedeceğine kendisi karar verir.

DAHA FAZLA BİLGİ Beklenmedik Güncellemeler: Subject nesnesi, Observer nesnelerindeki değişikliklere karşı kördürler. Subjectte yapılan anlaşılır ve zararsız bir değişiklik, observerlar ve observerlara bağlı nesnelerde büyük değişiklikler yapılmasına neden olabilir Yani Değişimlerinin etkilerini bilen subject değildir

Örnek Problem Kamil Koç otobüs firmasıdır. Firmamız için bilet kesen iki tane yazıhanemiz olsun. Balgat yazıhanesi ve Kızılay yazıhanesi. Bu iki yazıhane müşteriler için sefer bilgilerini tutsun. Yeni bir sefer eklendiği zaman bizim seyahat yazıhanelerimizin bu sefer bilgilerini de ekleyeceklerini garanti etmeliyiz.

Strateji Sistem, Kamil Koç tarafından bir sefer eklendiğinde bunu otomatik olarak yazıhanelere bildirmelidir. Tasarım yeni yazıhanelere, mevcut sistemde minimum değişiklik yapılarak yer sağlamalıdır.

Observer ile Çözüm

Çözüm - Kod SUBJECT public abstract class Subject { private ArrayList observers=new ArrayList(); public void AddObservers(Observer observer) observers.Add(observer); } public void RemoveObserver(Observer observer) observers.Remove(observer); public void Notify() foreach(Observer observer in observers) observer.UpdateKamilKocsRout(this);

Çözüm - Kod Observer public interface Observer { void UpdateKamilKocsRout(object Traveller); }

Çözüm - Kod ConcreteObservers public class KızılayYazanesi:Observer { public void UpdateKamilKocsRout(Object subject) if( subject is KamilKoc) AddRoutforKamilKoc((KamilKoc)subject); } private void AddRoutforKamilKoc(KamilKoc traveller) Console.WriteLine("new rout No. " + traveller.TravelRout + " Veri Tabanina Eklendi");

Çözüm - Kod ConcreteObservers public class BalgatYazanesi:Observer { public void UpdateKamilKocsRout(Object subject) if( Traveller is KamilKoc) AddRoutforKamilKoc((KamilKoc)subject); } private void AddRoutforKamilKoc(KamilKoc traveller) Console.WriteLine("new rout No. " + traveller.TravelRout + " Veri Tabanina Eklendi");

Çözüm - Kod class Client { [STAThread] static void Main(string[] args) KamilKoc KK= new KamilKoc("EC 2012",2230); KizilayYazanesi Kizilay=new KizilayYazanesi(); BalgatYazanesi Balgat=new BalgatYazanesi(); KK.AddObservers(Kizilay); KK.AddObservers(Balgat); KK.AddNewRout(); }

Java Kesiti- Tersten bakalım ! public class Customer{ static private Vector myObs; static{ myObs = new Vector(); } public static void attach(MyObserver o) { myObs.addElement(o);} public static void deattach(MyObserver o) { myObs.removeElement(o);} public static String getState() { // nesnenin durumunu gösteren bilgiyi yayınlayacak kod parçası } public void notifyObs() { for (Enumaration e = myObs.elements(); e.hasMoreElements;) ((MyObserver) e).update(this); interface MyObserver{ void update(Customer myCust) } class AddrModification implements MyObserver { public AddrModification () {} public void update(Customer myCust){ //do addressModificatios

Avantajları Subject, observer’ının içeriğinden haberdar olmadığından, subject – observer arası ikili ilişki en az seviyededir. Bu da sistemi iki bağımsız katmana ayırır. Observer Pattern, broadcast iletişimi destekler. Kim olduğundan ve sayısından bağımsız olarak güncellemelerin gerçekleşmesini sağlar. Sisteme her zaman yeni observer’lar eklenebilir, çıkartılabilir.

Dezavantajları Observer nesnesi güncellemek için kendisine gerekmese dahi değişen nesnenin tüm bilgilerine ulaşıyor İkili ilişkiler azaltıldığı için, her ne kadar yeniden kullanılabilirlik artsa da,nesneler arasındaki bağımlılıkları koda bakarak anlamak zorlaşır. Observer’ların içeriği bilinmediğinden güncellemelerin etkisi kestirilemez. Bu riskli!!!mi???

Observer Pattern: Known Uses • AWT Event handling – ActionListener, MouseListener, MouseMotionListener, … • Swing: Model-View separation – JTable – JList • Image Observer • Java Beans Event Notifications

COMPOSITE PATTERN

Composite Problem In graphics applications, the user can group components to form larger components A simple implementation: define classes for graphical primitives such as Text and Lines plus other classes that act as containers for these primitives. Code that uses these classes must treat primitives and container objects differently, even if most of the time the user treats them identically.

Composite The key to the composite pattern is an abstract class that represents both primitives and their containers Graphic Draw() Add(Graphic g) RemoveGraphic) GetChild(int) Client Line Draw() Circle Draw() Picture Draw() Add(Graphic g) RemoveGraphic) GetChild(int) Children forall g in graphics g.Draw() add g to list of graphics

Composite Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly

Structure Component Client Composite Leaf Children Operation() Add(Graphic g) RemoveGraphic) GetChild(int) Client Leaf Operation() Composite Operation() Add(Graphic g) RemoveGraphic) GetChild(int) Children forall g in graphics g.Draw()

Other examples Software System: Definition: A software system consists of subsystems which are either other subsystems or collection of classes Software Lifecycle: Definition: The software lifecycle consists of a set of development activities which are either other activities or collection of tasks File Folder:

Collaborations Clients use the component class interface to interact with objects in the composite structure. If the recipient is a Leaf, then the request is handled directly. If the recipient is a Composite, then it usually forwards requests to its child components, possibly performing additional operations before and/or after forwarding.