4 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ırTasarı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ış.
5 Örüntüyü babası tanımlıyor Alexander’ın örüntü (pattern) tanımı“Each pattern describes a problem1)which occurs over and over again in our environmentand then2)describes the core of the solution to that problem,in such a way that3)you can use this solution a million times over,without ever doing it the same way twice”
6 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]
7 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.
8 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).
9 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 katalogdurNesneye yönelik tasarımı örüntü temellerine oturtarak yeniden gözden geçirmişlerdir.
10 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)
11 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 fikirdirOrtak 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ğlarProblemi örüntü tabanlı incelemek nesneye yönelik tasarımda üst düzey öngörüyü oluştururTasarım örüntüleri ile daha kolay değiştirilen ve bakımı yapılan kodlar ortaya çıkar (tecrübe göstermiştir)
12 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”
15 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)
16 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.
17 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ŞTURULMASIveYAZILIM GEREKSİNİMLERİNİN MODELLENMESİ
18 EK: Requirements/Glossary Course Registration System Glossary Version 2.0Revision HistoryDate Version Description Author26/Dec/ Draft version Bill Collings19/Feb/ Moved some of the terms to the Wylie College glossary Bill CollingsGlossary1.IntroductionThe 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. DefinitionsAlternative course selectionA student might choose to register for one or more alternative courses, in case one or more of the primary selections are not available.Billing SystemPart of the university's Finance System used for processing billing information.
19 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.
20 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.
21 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 AnalystOptional. Produced in early Elaboration, during requirements elicitation.
22 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.
23 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.
24 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.
25 Analysis ModelIn 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 detailsAgain, 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 customerWhereas Use Cases are described in the language of the customer, the Analysis Model is described in the language of the developer:Boundary ClassesEntity ClassesControl Classes
26 Boundary ClassesBoundary 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:
27 Entity ClassesEntity classes are used within the Analysis Model to model persistent informationOften, entity classes are created from objects within the business object model or domain model
28 Control Classes The Great Et Cetera Control classes model abstractions that coordinate, sequence, transact, and otherwise control other objectsIn Smalltalk MVC mechanism, these are controllersControl classes are often encapsulated interactions between other objects, as they handle and coordinate actions and control flows.
29 İ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ı?
30 Adapter PatternVarolan 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.
31 Adapter: Class ModelAdapter is based on the delegation form because an Adapter object delegates the command to the targeted command.
34 Adapter Problem TextView getExtent() Shape Line PolygonShape BoundingBox()Createmanipulator()LinePolygonShapeDrawingEditortextTextShapeBoundingBox()Createmanipulator()Return text.getExtent()Return new TextManipulatorAnother way?
35 Adapter ve Adaptee arasında delegasyon (delegation) vardır. Nesne AdaptörClientTargetRequest()AdapteeExistingRequest()adapteeAdapterRequest()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
36 Class Adapter (Açıklamalara ingilizce yer verdim) ClientTargetRequest()AdapteeExistingRequest()adapteeAdapterRequest()A class adapter uses multiple inheritance to adapt one interface to anotherNot as flexible as object adapter – cannot work with multiple adapteesLet adapter to override some of adaptee’s behavior. Object adapter cannot override adaptee’s behavior.
37 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
40 Sarmalama TürleriEncapsulation 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 iletilerarayüzde yer alıyorsa gerçekleştirimleriArayüzde yer almıyorsa varoluşlarıSarmalanmıştırEncapsulation 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.
41 Soru1Rectangle kendi verisini saklamış durumda ve ekrana bir çerçeve ile çıkıyor.RectangleSpecialBorder ise aynı diktörgeni ekrana farklı bir çerçeve ile çiziyorSizce her iki maddede belirtilen durum için yandaki tasarımlar uygun mudur?2
42 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şecekAynı anda bir kaç çerçeveleme yöntemi kullanılmak istenirse önceki yaklaşımların çözümü nedir ?
43 Değişen ne ? GoF derki:”Find what is varying and encapsulate it” Problem:Farklı hayvan karakteristikleri modellenecekHer hayvan farklı sayıda bacağa sahipHayvan nesnesi bu bilgiyi saklamak ve sunmak zorundaHer hayvan farklı türde hareket yeteneğine (belki yeteneklerine) sahipHer hayvan nesnesi bir noktadan diğerine gitmek için kendi hareket tipine göre ne kadar süreceğini bilmek zorundaModelinizi sununuz
45 Strategy Pattern “Design with change in mind” ...GoF.. Değişikliklerin olabileceği noktaları doğru tespit etmek gerekirBu yaklaşımın temelleri (GoF’un kitabından)Program to inteface, not an implementationFavor object aggregation over class inheritanceConsider what should be vairable in your designNelerin değişikliğe sebep olabileceği değil yeniden tasarım yapmadan (redesign) neleri değiştirebilmek istediğimiz tespit edilmeli
46 ProblemBir 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.
47 Yeni gereksinimBeklenen değişiklik gerçekleşiyor ve Türkiye, Almanya ve Kanada’dan verilecek siparişler için farklı vergilendirme usülleri uygulanacakBu değişiklikler için ilk akla gelenlerCopy-pasteSwitch-ifInheritance
48 If – Switch çözümü Siparişin calcTax()’i içinde //handle tax switch (myNation){TR://Handle TR tax rulesGER://Handle GER tax rulesCND://Handle CND tax rules}
49 Kalıtımla ÇözümSizce beklenen potansiyel bir sorun var mı ?
50 SorunEğ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ğilseVergi usulü ülkeden ülkeye değişiyor ama teslim tarihi kıtadan kıtaya değişiyor
51 Temel prensiplere bir bakış “Find what varies and encapsulate it in a class of its own”“Contain this class in another class”
52 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”
53 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)
55 Strategy Pattern değerlendirmesi Encpsulating bussiness rulesLower cost of unit test : Strategy kısmı kendi başına sınanabilirSorular1. 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 ?
57 Decorator PatternDecorator 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.
58 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 !!! )
59 Structure of Decorator Pattern Decorator Pattern İçin Genel Yapı
60 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.Decoratormaintains a reference to a Component object and defines an interface that conforms to Component's interface.ConcreteDecoratoradds responsibilities to the component.
61 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 )
62 1. ÇözümHer olası pizza malzemesi seçimi için bir sınıf yarat !
63 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; ...
64 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
66 3. ÇözümPizza malzemelerinin her birini Decorator Pattern’daki decorator olarak düşün.ComponentConcreteComponentDecoratorConcreteDecorator
67 Java Kodupublic class Misirli extends MalzemeliPizza{ protected Pizza pizza; public Misirli (Pizza pizza){ this.pizza = pizza; } public double cost(){ return 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 pizza.cost();}} public class Zeytinli extends MalzemeliPizza{ public Zeytinli(Pizza pizza){ this.pizza = pizza;} return pizza.cost();}}* Sop => System.out.println
68 Değerlendirme public class YeniMalzeme extends MalzemeliPizza{... Diğer çözüme göre daha az sayıda sınıfMalzeme ekleme/çıkarma daha kolaypublic class YeniMalzeme extends MalzemeliPizza{...Pizzada her çeşit malzeme bir arada bulunabilir.Her ne kadar sadece malzemeler tekil tanımlanmış ise de...
70 + 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.
71 + lar ve - ler2 . 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
72 + lar ve - ler3 . A decorator and its component aren't identical. 4 . Lots of little objects.
73 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...
74 Decorator Pattern Problem - 2 Header ve footer lar farklı türde ise ve farklı sayıda tetiklenmesi gerekiyorsa :Header1Header2TicketFooter1HeaderTicketFooterHeader2Header1TicketFooter2
76 Java Kesitiabstract 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();
77 Java Kesiti - Devampublic 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
78 Örnek çıktılar için kullanımlar HEADER1HEADER2SALESTİCKETFOOTER1HEADER1SALESTİCKETFOOTER1Örnek nesne yaratımlarıreturn (new Header1( new Footer1 (newSalesTicket())))return(new Header1 (new Header2 (new Footer1(new SalesTicket()))))
80 TANIMBir 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
81 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
82 Nerelerde KullanılırBir nesnedeki değişiklik başka nesnelerde otomatik olarak değişiklik gerektiriyorsaBir nesnenin başka nesneleri kim olduklarına bakmaksızın bir durumdan haberdar etmeleri gerektiğinde
83 İ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.
84 İ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.
86 SUBJECTKendi 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.
87 OBSERVERGüncelleştirme haberini çok biçimli verebilmek için tanımlanmış bir arayüz.
88 ConcreteSubject ConcreteObserver nesnelerince durumu takip edilir İzlenen nesnedirDurum değişikliklerinde bu değişimi bildirmekle yükümlüdür
89 ConcreteObserver Gözlemleyen nesnedir. Subject ile tutarlı kalması için gereken güncellemeleri bilir
90 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.
91 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.
92 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
93 Örnek ProblemKamil 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.
94 StratejiSistem, 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.
101 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
102 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.
103 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???
106 Composite ProblemIn graphics applications, the user can group components to form larger componentsA 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.
107 CompositeThe key to the composite pattern is an abstract class that represents both primitives and their containersGraphicDraw()Add(Graphic g)RemoveGraphic)GetChild(int)ClientLineDraw()CircleDraw()PictureDraw()Add(Graphic g)RemoveGraphic)GetChild(int)Childrenforall g in graphicsg.Draw()add g to list of graphics
108 CompositeCompose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly
109 Structure Component Client Composite Leaf Children Operation() Add(Graphic g)RemoveGraphic)GetChild(int)ClientLeafOperation()CompositeOperation()Add(Graphic g)RemoveGraphic)GetChild(int)Childrenforall g in graphicsg.Draw()
110 Other examples Software System: Definition: A software system consists of subsystems which are either other subsystems or collection of classesSoftware Lifecycle:Definition: The software lifecycle consists of a set of development activities which are either other activities or collection of tasksFile Folder:
111 CollaborationsClients 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.