CREATIONAL PATTERNS

1. Abstract factory (KIT) je patern koji obezbeuje interfejs za kreiranje familije zavisnih objekata
bez specificiranja njihove konkretne klase.
Koristi se:
Kad elimo da nam sistem bude nezavistan od objekata koje kreira;
Kada sistem elimo da konfiguriemo sa nekom familijom objekata;
Kada nam treba neko stablo objekata;
Kada hoemo da napravimo klasnu biblioteku produkata, a ne elimo da otkrijemo
njihovu implementaciju, ve samo njihov interfejs.
Na slici je prikazan konkretan primer Abstract factory paterna. Sutina ovog paterna je
polimoefizam.

Uesnici:
AbstractFactory (WidgetFactory)
Deklarie interfejs za operacije koje kreira apstraktni objekat.
ConcreteFactory (MotifVidgetfactory, FMWidgetFactory)
Implementira operacije za kreiranje konkretnih objekata.
AbstractProduct (Window, ScrollBar)
Deklarie interfejs za odreenu vrstu objekta.
ConcreteProduct (MotifWindow, MotifScrollBar)
Definie objekat koji se kreira pomou konkretnog factory-a i implementira AbstractProduct
interfejs.
Client
Koristi samo interfejs definisan pomou AbstractFactory-a i AbstractProduct klasa.


Na sledeoj slici prikazan je uopten primer Abstract factory paterna:


















2. Builder razdvaja konstrukciju kompleksnog objekta od njegove reprezentacije.

Koristi se:
Kada reprodukciju objekta koji se kreira elimo da razdvojimo od njegovih delova;
Kada moramo da dozvolimo da jedan kompleksni objekat ima vie reprodukcionih
dijagrama.

U konkretnom primeru sa tektom ubaen je Builder sa dve metode koja nasleuju dve klase (u
crteu nedostaje strelica ka TextConvertoru).
Obe klase imaju pomone metode koje kreiraju instance. Postie se da RTFReader kreira ASCII
tekstove, a da pritom ne zna sa kojim tekstovima radi.









Uopten primer:

Uesnici:

Builder (TextConverter)
Specificira apstraktni interfejs za kreiranje delova objekata.
ConcreteBuilder (ASCIIConverter, TeXConverter)
o Konstruie delove objekata implementacijom Builder interfejsa.
o Definie i vodi rauna o reprezentaciji koju stvara.
o Obezbeuje interfejs za preuzimanje objekata.
Director (RTFReader)
Konstruie objekat korienjem Builder interface-a.
Product (ASCIIText, TeXText)
o Predstavlja sloen objekat u izgradnji. ConcreteBuilder pravi unutranju reprezentaciju
objekta i definie procese od kojih je sastavljen.
o Obuhvata klase koje definiu sastavne delove, ukljuujui interfejs za sastavljanje delova
u finalni rezultat.










3. Factory method (Virtual constructor) Definie interfejs za kreiranje objekata, ali dozvoljava
podklasama da instanciraju odreene objekte.

Koristi se:
Kada klasa ne moe da odlui koji objekat treba da kreira;
Klasa oekuje da njene podklase definiu objekat koji se kreira;
Klasa delegira odgovornost nekoj od podklasa.

Primer: Imamo dokumenta i elimo da ih naa aplikacija kreira. CreateDocument() je metod koji
kreira dokumenta.












Uopten primer:

Uesnici:

Product (Document)
Definie interfejs objekta koji factory metoda kreira.
ConcreteProduct (MyDocument)
Implementira Product interfejs.
Creator (Application)
o Deklarie factory metodu, koja vraa objekat tipa Product. Creator takoe moe
definisati podrazumevanu implementaciju factory metode koja vraa podrazumevani
ConcreteProduct objekat.
o Moe pozvati Factory metod za kreiranje Product objekta.
















4. Prototype specificira tipove koje elimo da kreiramo korienjem protipa.

Koristimo ga:
Kada hoemo da sistem bude nezavistan od klasa koje kreira;
Kada elimo da izbegnemo praralelnu hijerarhiju klasa;
Kada klasa ima samo nekolicinu razliitih kombinacija.

Primer: Koristimo metod Clone koji moe da napravi jo jednu takvu instancu klase. Svaka
podklasa mora imati implementiranu tu metodu. Ako objekat ne postoji moe da se odlui da li
e se napraviti novi objekat ili e se klijentu vratiti neki postojei objekat koji e mu posluiti u te
svrhe.
Svako ko nasleuje grafiku ima Draw i Close. Kada na primer grafiki hoemo da nacrtamo 1000
nota pomou nekog alata, glupo bi bilo da pravimo 1000 instanci, ve e se proveriti da li tako
neto ve postoji, pa ako postoji vratie se to neto.
Sa ovim paternom tedimo memoriju potrebnu za pravljenje objekata.













Uopten primer:



Uesnici:

Prototype (Graphic)
Deklarie interfejs za kloniranje samog sebe.
ConcretePrototype (Staff, WholeNote, HalfNote)
Implementira operaciju za kloniranje samog sebe.
Client (GraphicTool)
Kreira novi objekat traei od Prototipa da klonira samog sebe.

















5. Singltone Omoguava da jedna klasa ima samo jednu instantu i obezbeuje globalni pokaziva
na nju.

Koristi se:
Kada elimo da imamo samo jednu instancu jedne klase;
Kada jedina instanca treba da bude proiriva sa podklasom i klijenti trebaju da
budu u mogunosti da koriste proirenu instancu bez modifikovanja svog koda.

Primer: Klasa Singlton pravi Singltone.



Uesnici:

Singleton
o Definie instance operacije koja dozvoljava klijentu pristup do unikatne instance.
o Odgovorna je za kreiranje svoje unikatne instance.




















STRUKTURALNI PATERNI

1. Adapter konvertuje interfejs jedne klase u drugi interfejs, koji klijent oekuje.

Koristi se:
Kada se ne znaju interfejsi izmeu klase i klijenta;
Kada hoemo da napravimo reusable klasu;
Kada klasu trebamo da nasledimo na odgovarajui nain.

Primer: Klijet je opet klasa (objekat). On hoe da koristi klasu Adaptee, a ona ima metodu
SpecificRequest za koju klijent ne zna. On hoe da koristi Request.
Ubacujemo dve klase izmeu Target koji ima samo Request (Target je apstraktna klasa, a
Adapter implementira metodu Request() ).



Uesnici:

Target
definie domain-specific interfejs koji Client koristi.
Client
Sarauje sa objektima u skladu sa Target interfejsom.
Adaptee
Definie postojei interfejs koji zahteva prilagoavanje.
Adapter
Prilagoava interfejs Adaptee-a na interfejs Target-a.


2. Bridge razdvaja apstrakciju od implementacije tako da mogu da se menjaju relativno
nezavisno.

Koristi se:
Kada elimo da izbegnemo trajno vezivanje izmeu apstrakcije i njene
implementacije.
Kada hoemo da i apstrakcija i implementacija budu proirive pomou podklasa.
Kada promene na implementaciji ne trebaju da utiu na klijenta.
Kada hoemo da delimo implementaciju izmeu vie raznih objekata.

Primer: Klijenti koji su vezani za apstrakciju zovu metod Operation i on zove Operation kod
implementacije. Nezavisni su i moemo ih proirivati zato smo i razdvojili apstrakciju i
implementaciju.



Uesnici:

Abstraction
o Definie apstrakcioni interfejs.
o Odrava reference na objekat tipa Implementor.
RefinedAbstraction
Proiruje interfejs koji je definisao Abstraction.
Implementor
Definie interfejs za implementacione klase.
ConcreteImplementor
Implementira Implementor interfejs i definie konkretnu implementaciju.


3. Composite Omoguava kreiranje staba tj stablaste strukture. Samo stablo obezbeuje
strukturu celina-deo. Omoguava jednako tretiranje vorova i listova.

Koristi se:
Kada nam treba stablasta struktura.
Kada klijent ne treba da brine da li poziva metode za koren ili list stabla.

Primer: Klijent zove implementaciju Component (Trai da izvri neto nad nekim vorom).
Component ima metode, koje nasleuju dve klase List i Composite (tj. Novi vor stabla koji ima
decu).


Uesnici:

Component
o Deklarie interfejs za objekte u kompoziciji
o Implementira osnovno ponaanje za interfejse koji su zajedniki za sve klase.
o Deklarie interfejs za pristup i upravljanje komponentama deteta.
o Opciono definie interfejs za pristup komponentama roditelja.
Leaf
o Reprezentuje objekat u kompoziciji. List nema dece.
o Definie ponaanje za primitivne objekte u kompoziciji.
Composite
o Definie ponaanje za komponente koje imaju decu.
o uva komponente dece.
o Implementira operacije vezane za decu u Component interfejsu.
Client
Manipulie objektima u kompoziciji kroz Component interfejs.
4. Decorator dodaje dodatne odgovornosti objektu dinamiki. Misli se na atribut ili metod.
Omoguava alternativna nasleivanja.

Koristi se:
Kada elimo da dodamo odgovornost dinamiki bez da modifikujemo objekat.
Kada elimo da moemo da vratimo te odgovornosti.
Kada je nasleivanje iz nekog razloga nepraktino. (Kada je originalna klasa
suvie velika ili komplikovana).
Kada je definicija klase skrivena.

Primer: ConcreteComponet je klasa kojoj neto trebamo da dodamo. Iznad nje napravimo klasu
kao to je ona, ispod dodamo dekorator koji e imati posebnu metodu koja e pozivati
originalnu operaciju. Dekorator moemo naslediti sa proizvoljnim brojem dekoratora, a da tim
novim dodamo npr. novi atribut ili metod. Tako smo izbegli da nasledimo taj konkretni metod,
jer smo napravili kopiju te klase, pa onda nju nasleujemo.


Uesnici:

Component
Definie interfejs za objekte koji mogu imati odgovornost da ih dodaju dinamiki.
ConcreteComponent
Definie objekte za koje se mogu zakaiti dodatne odgovornosti.
Decorator
Odrava referencu na Component objekat koji definie interfejs koji odgovara Component
interfejsu.
ConcreteDecorator
Dodaje odgovornosti komponentama.
5. Facede omoguava unificirani interfejs nekom skupu komponenti. Imamo komplikovan
podsistem i elimo da sakrijemo strukturu podsistema. Fasada e je sakriti i prikazati klijentu u
nekoj formi.

Koristi se:
Kada hoemo jednostavan prikaz interfejsa.
Kada imamo mnogo zavisnosti meu klijentima.
Kada hoemo da lejerujemo na podsistem.

Primer: Kompajler Imamo desetak klasa koje ga nasleuju. To je komplikovan podsistem.
Fasada e sve te klase da stavi u jedinstveni interfejs. Neko od spolja ne moe da aka po
podsistemu.



Uesnici:

Facade (Compiler)
o Zna koji podsistem klasa je odgovoran za zahtev.
o Delegira zahtev klijenta odgovarajuem podsistemu objekta.
Klase Podsistema (Scanner, Parser, ProgramMode, etc.)
o Implementiraju funkcionalnost podsistema.
o Odrauju posao koji se prosleuje Facade objektu.
o Nemaju nikakvo znanje o fasadi, nemaju referenci na nju.


6. Flyweight koristimo deljenje da omoguimo veliki broj objekata koje trebamo da kreiramo.
Neemo za svaki objekat kreirati nov objekat ve emo napraviti flyweight objekat i klijentu
emo kad god je mogue vratiti postojei objekat.
Primenjujemo ga samo kada su svi ovi uslovi ispunjeni:
Aplikacija nam koristi veliki broj objekata.
Cena memorije je velika, a nama treba mnogo memorije.
Veina stanja objekata moe da se izvue iz objekta.
Velike grupe objekata se mogu zameniti malim brojem objekata.
Sama aplikacija ne zavisi od identiteta tog objekta.

Primer: Flyweight je klasa koja ima operaciju sa spoljanjim stanjima. Ako izvadimo neke
atribute mnogi objekti se svode na jedan. Concret Flyweight je instanca svih tih objekata koji se
mogu svesti na isto, a Unshare pamti sve te atribute koji su razliiti, odnosno, ne mogu da budu
deljeni. Flyweight factory e proveriti da li postoji Flyweight objekat koji moemo vratiti, ako ne
postoji tek onda kreiramo nov objekat i on je iz Unshare dela. Concrete Flyweight e npr vratiti
1000 pokazivaa na jedan objekat, koji treba da se koristi (ako moe da se svede na isto).
Ovako se tedi memorija, jer ako imamo Flyweight objekat koji moe da se kreira, ne
moramo da pravimo nove objekte. Dovoljan nam je pokaziva na FW objekat.










Uesnici:

Flyweight
Deklarie interfejs kroz koji flyweight moe da prima i reaguje na odreena stanja.
ConcreteFlyweight
Implementira Flyweight interfejs i dodaje prostor za unutranje stanje. ConcreteFlyweight
objekat mora biti deljiv.
UnsharedConcreteFlyweight
Ne mogu sve Flyweight podklase da budu vidljive. Flyweight interfejs omoguava deljenje, ali ga
ne prisiljava. Zajedniko za UnsharedConaeteFlyweight objekte je da imaju ConcreteFlyweight
Objekat kao dete na nekom nivou flyweight strukture objekta.





































7. Proxy obezbeuje placeholder za neki drugi objekat tj. Pomou njega kontroliemo pristup
nekom drugom objektu od strane ostalih objekata.
Imamo vie razliitih vrsta Proxy-a:
Remote proxy imamo vaan objekat i sa proxy-jem u drugom paketu pristupam tom
objektu.
Virtual proxy kreira skup objekara na zahtev.
Protection proxy kontrolie pristup tom objektu.
Smart proxy pametna referenca na objekat. Ako je broj referenci nula, moemo
unititi taj objekat.

Primer: elimo da kontroliemo RealSubject tako to iznad njega stavimo apstraktnu klasu
Subject i nju nasledimo sa Proxy-jem. Ona e imati Request za taj objekat. Tek ako sme da mu
pristupi zove pravi Request iz RealSubject-a.

















Uesnici:

Proxy
o Odrava referencu koja dozvoljava pristup proxy-ju do real subject-a. Proxy moe imati
referencu na Subject ako su interfejsi ReaISubject-a i Subject-a isti.
o Obezbeuje identian interfejs za Subject tako da proxy moe biti zamenjen za real
subject.
o Kontrolie pristup do real subject-a i moe biti odgovoran za kreiranje ili brisanje istog.
o Ostale odgovornosti zavise od vrste proxy
remote proxy je zaduen za enkodiranje zahteva i njihovih argumenata, kao i za
slanje enkodiranog zahteva real subject-u u razliiti adresni prostor.
virtual proxy moe hvatati dodatne informacije o real subject-u.
protection proxy proverava da li caller ima dozvolu za pristup neophodnu za
izvravanje zahteva.
Subject
Definie zajedniki interfejs za RealSubject i Proxy kako bi Proxy mogao biti korien gde god
RealSubject oekuje.
RealSubject
definie real objekat koji proxy reprezentuje.





























BEHAVIOURAL PATERNI

1. Chain of responsability Omoguava da vie od jednog objekta ima ansu da obradi neki
zahtev.

Koristi se:
Kada elimo da vie objekata obradi zahtev, a objekti su nepoznati.
Kada hoemo da pustimo zahtev nekolicini objekata, a ne znamo ko e
odgovoriti.
Kada hoemo da skup objekata odgovori dinamiki.

Primer: Klijent alje zahtev na Handler i njega nasleuju dva konkretna Handler-a, koji izvravaju
zahtev ako je to mogue (if-else).












Opti primer:




Uesnici:

Handler (HelpHandler)
o Definie interfejs za upravljanje zahtevima.
o Opciono implementira naslednika veze.
ConcreteHandler (PrintButton, PrintDialog)
Upravlja zahtevima koji su odgovorni za to ko moe da pristupi nasledniku ako ConcreteHandler
moe da podri zahtev, uradie to, u suprotnom prosledie zahtev svom nasledniku.
Client
Inicira zahtev ka ConcreteHandier object na lancu.















2. Command neki zahtev ili naredbu spakujemo kao objekat i parametrizujemo klijente sa tim
objektom. On nam omoguava da zahtevi budu u redu opsluivanja i moemo da izbacimo
zahtev iz reda opsluivanja kada ga ne elimo.

Koristimo ga:
Kada hoemo da imamo UNDO.

Primer: Klijent eli da izvri akciju. Ubacimo apstraktnu klasu Command. U klasi
ConcreteCommand koja je nasleuje klasu Command pozivamo Action. To sada stoji u redu
opsluivanja zahteva, a Invoker e svakih pola sata uzimati po jednu komandu iz reda
opsluivanja i zavravati je. Klijent kreira konkretne komande. Ubacili smo objekte koji sadre
naredbe.



Uesnici:

Command
Deklarie interfejs za izvravanje operacije.
ConcreteCommand
o Definie vezu izmeu Receiver object-a i akcije.
implementira Execute pozivajui odgovarajui operation(s) na Receiver.
Client
Kreira ConcreteCommand objekat i podeava njegov receiver.
Invoker
Pita komadu da uzme zahtev.
Receiver
Zna kako da izvri operacije koje su povezane sa preuzimanjem zahteva.

3. Interpreter vezan je za kompajler. Kada imamo programski jezik ovaj patern nam daje
prezentaciju te gramatike i daje nam mogunost da izvravamo taj jezik.

Koristi se:
Kada imamo ulazni jezik koji treba interpretirati.
Kada je gramatika jezika jednostavna.

Primer: Imamo terminalne(one su delovi jezika kao npr. kljune rei) i neterminalne
izraze(konstrukcije jezika, naredbe, izrazi,).
Imamo apstraktni izraz koga nasleuju terminalni i neterminalni izrazi. Oni imaju metode
Interpreter i ta metoda interpretira dati vor. Klijent ima pokaziva na tu apstraktnu strukturu i
ima svest o nekom kontekstu npr. vrednost promenljivih.

















Uesnici:

AbstractExpression
Deklarie apstraktnu Interpret operaciju koja je zajednika za sve vorove u apstraktnom sintaksnom
stablu.
TerminalExpression
o Implementira operaciju interpretera koja je spojena sa sa terminalnim simbolima u gramatici.
o Instanca je neophodna za svaki terminalni izraz u reenici.
NonterminalExpression
o Jedna ovakva klasa je neophodna za svako pravilo u gramatici.
o Odrava instance promenljivih tipa AbstractExpression za svaki od simbola.
o Implementira Interpret operaciju za neterminalne simbole u gramatici.
Context
Sadri globalne informacije o interpreteru.
Client
Gradi apstraktno sintaksno stablo koje predstavlja oidreenu reenicu u jeziku ija se gramatika definie.
Apstraktno stablo je sastavljeno od instanci iz NonterminalExpression i TerminalExpression klasa.































4. Iterator obezbeuje pristup elementima nekih agregata (kolekcija elementa, lista) bez znanja
kako je implementirana.

Koristi se:
Kad pristupamo kolekciji bez interne prezentacije.
Da obezbedi viestruke prolaze kroz kolekciju
Da obezbedi jedinstveni interfejs za popreno razliite agregate struktura.

Primer: Kod Iteratora biramo metode koje elimo da imamo. Aggregate je apstraktna klasa, dok
ConcreteAggregate predstavlja elemente koji idu u kolekciju. On kreira iterator. Kao parametar
daje sebe da bi konkretan Iterator napravio kolekciju npr. listu tih uda. Iterator je opta
kolekcija.



Uesnici:

Iterator
Definie interfejs za pristup elementima.
Concretelterator
o Implementira interfejs iteratora.
o Vodi rauna o trenutnoj poziciji u poprenoj listi agregata.
Aggregate
Definie interfejs za kreiranje Iterator objekata.
ConcreteAggregate
Implementira iteratorski kreacioni interfejs kako bi vratio instancu odgovarajueg Concretelterator.


5. Mediator definie kako nea skupina objekata komunicira. Smanjuje suvie veliko vezivanje
objekata. On pokuava da smanji tu poziciju i daje nam mogunost da ponovo iskoristimo jedan
od njih.

Koristi se:
Kada objekti komuniciraju na dobar, ali suvie kompleksan nain.
Kada svaki objekat komunicira sa puno drugih objekata.
Kada je ponaanje objekata uzrokovano nasleivanjem, a ne elimo puno
nasleivanja.

Primer: Kolega nema gotovo nikakav interfejs, jer ga nasleuju sve kolege. Mediator je
apstraktna, a opta klasa je ConcreteMediator i ona stoji izmeu svakog kolege.



Uesnici:

Mediator
Definise interfejs za komunikaciju sa Colleague objektima.
ConcreteMediator
o Implementira kooperativno ponaanje koordinacijom Colleague objekata.
o Zna i odrava svoje kolege.
Colleague classes
o Svaka Colleague klasa zna svog Mediator objekta.
o Svaki kolega komunicira sa medijatorom.



6. Memento bez ometanja enkapsulacije hoemo da sauvamo neko stanje objekta tako da
moemo da nekada da vratimo to stanje objekta.

Koristi se:
Kada nam treba snimak nekog objekta;
Kada ne elimo da izloimo taj objekat drugima.

Primer: Originator elimo da sauvamo. Ubacujemo klasu Memento, koja ima metode get i
setState. Originator ima se i CreateMemento. Prva metoda uva neko stanje, a onda ga vraa na
prethodno stanje. Caretaker brine o mementovima, ali niko spolja ne vidi strukturu originalnog
objekta.



Uesnici:

Memento
o uva interno stanje Originator objekta. Memento moe da sauva koliko god je potrebno
internih stanja.
o Zabranjuje pristup svim objektima koji nisu originator
Originator
o Kreira memento koji ima sliku trenutnog stanja.
o Koristi memento da bi vratio preanje stanje.
Caretaker
Odgovoran je za uvanje mementa.



7. Observer Kada jedan objekat promeni neko stanje preko Observera obavetavamo sve
zainteresovane objekte da mu se stanje promenilo.

Koristi se:
Kada promenimo jedan objekat
Kada neki objekat treba da obavesti drugi o promeni stanja, a ne zna ih.

Primer: Apstraktna klasa Subject ima attach koji dodaje Observer, detach za skidanje i Notify koji
obavetava kada se objekat promeni. ConcretObject menja svoje stanje na osnovu stanja
promene Subject-a u metodi Update(). Kod ConcreatSubject getState vraa konkretno stanje.
Primer je GUI aplikacija.


Uesnici:

Subject
o Zna svoje observere.
o Obezbeuje interfejs za kaenje i skidanje observer objekata.
Observer
Definie interfejs za update za objekte koji bi trebali da obaveste subject o promenama.
ConcreteSubject
alje obavetenje svom observeru kada se stanje promeni
ConcreteObserver
o uva referencu na konkretni subjekt.
o uva stanje koje bi trebalo da ostane konzistentno sa subjektom.
o Implementira Observer updating interface kako bi odrao njegovo stanje sa subjektom.
8. State dozvoljava objektu promenu ponaanja kad mu se promeni neko stanje. Izgledae kao da
objekat menja klasu.

Koristi se:
Kada ponaanje objekta zavisi od njegovog stanja.
Kada imamo velike uslovne naredbe koje nam zavise od stanja. Koristi se za
izbegavanje switch bad small-a.

Primer: State je apstraktna klasa koju nasleuju konkretni state-ovi koji imaju razliite
implementacije. (Oblik nasleuju krug, trougao, Svi imaju metodu Draw, kada je state krug
crta se krug metodom DrawKrug). Objekat menja ponaanje u zavisnosti od stanja.



Uesnici:

Context
o Definie interfejs koji je u interesu klijenta.
Odrava instancu ConcreteState podklase koja definie trenutno stanje.
State
Definie interfejs za enkapsulaciju ponaanja koje je povezano sa odreenim stanjem Context-a.
ConcreteState podklase
Svaka podklasa implementira ponaanje koje je povezano sa stanjem Context-a.





9. Strategy definie familiju algoritama. Algoritam varira u zavisnosti od potrebe.

Koristi se:
Kada se mnoge povezane klase razlikuju samo u svom ponaanju.
Kada trebaju razliite varijante algoritma.
Kada algoritam koristi podatke za koje klijent ne zna.
Kada klasa ima vie ponaanja, a oni se pojavljuju kao viestruke uslovne
naredbe.

Primer: Svaka podklasa implementira algoritam. On zove jednu metodu, koja zove odgovarajui
algoritam. Primer Sortiranje ( Bubble, ...). U zavisnosti od potrebe sortiranja zovemo neki od
sortova.



Uesnici:

Strategy
Deklarie interfejse koji su zajedniki za sve podrane algoritme.
ConcreteStrategy
Implementira algoritme koristei Strategy interfejs.
Context
o Konfigurisan je sa ConcreteStrategy objektom.
o uva referencu na Strategy objekt.
Moe definisati interfejs koji Strategy-u daje da pristupi svojim podacima.



10. Template method Definie skeleton algoritam, ali dozvoljava podklasama da implementiraju
neke korake u tom algoritmu.

Koristi se:
Kada imamo invarijantne delove algoritma.
Kada trebamo da parametriujemo algoritam sa razliitim opcijama.
Kada elimo da kontroliemo dodatke za podklase.

Primer: Imamo metodu koja ima vie primitivnih operacija, pa ih klase naslednice
implementiraju. Znai AbstractClass ih ne implementira.



Uesnici:

AbstractClass
o Definie apstraktne primitivne operacije koje konkretna podklasa definie kako bi
implementirala korake algoritma.
o Implementira template method definiui skeleton algoritma. Template method poziva
primitivne operacije, kao i operacije definisane u AbstractClass-u ili u drugim objektima.
ConcreteClass
Implementira primitivne operacije kako bi iznela napolje specifikaciju podklase u algoritam.





11. Visitor slian je kao i KIT. elimo da veemo neku operaciju bez toga da menjamo klase.

Koristi se:
Kada imamo mnogo klasa kojima elimo da dodelimo ponaanje.
Kada imamo potencijalno mnogo nepovezanih operacija koje izvravamo nad objektima.
Kada se objekti u klasi retko menjaju, ali esto elimo da definiemo nove operacije.

Primer: Klijent zna za Visitor-a i strukturu objekta. Ubacimo klasu Element tako da moe da
primi neki visitor. Svaki visitor ima svoj konkretni metod tj. Implementaciju. Opti visitor
poseuje elemente A i B i moe im dodeliti neko ponaanje.


Uesnici:

Visitor
Deklarie Visit operaciju za svaku klasu ConcreteElement u strukturi objekta.
ConcreteVisitor
Implementira svaku operaciju deklariui Visitor-a.
Element
Definie Accept koja uzima visitor-a kao argument.
Concrete Element
Implementira Accept operaciju koju visitor-a uzima kao argument.
ObjectStructure
o Moe da nabroji svoje elemente.
o Moe da napravi interfejs visokog nivoa kako bi dozvolio visitor-u da poseti svoje elemente.