Oblikovni obrasci

Tehničko veleučilište u Zagrebu
Vrbik 8, Zagreb
Seminar
OBLIKOVNI OBRASCI U PROGRAMIRANJU
Student: Petar Marijanović
Zagreb, 25.10.2015

Napredne tehnike programiranja web servisa (.open-source) Seminarski rad
Stranica 2 od 36
Sadržaj
1. Dnevnik promjena dokumentacije ......................................................................................3
2. Opis seminarskog rada ........................................................................................................4
3. Pojmovnik ...........................................................................................................................5
4. Uvod....................................................................................................................................6
5. Obrazac Strategija (Strategy pattern) ..................................................................................7
6. Obrazac Promatrač (Observer pattern)..............................................................................10
7. Obrazac Stanje (State pattern)...........................................................................................14
8. Obrazac Naredba (Command pattern)...............................................................................19
9. Obrazac Jedini (Singleton pattern)...................................................................................23
10. Obrazac Adapter (Adapter pattern) ...............................................................................27
11. Obrazac Tvornica (Factory pattern) ..............................................................................30
12. Zaključak .......................................................................................................................34
13. Reference.......................................................................................................................35
14. Popis slika......................................................................................................................36

Stranica 3 od 36
1. Dnevnik promjena dokumentacije
Rev. Opis promjene/dodatka Autor Datum
0.1 Napravljen sadržaj i opći oblik seminara Marijanović 18.09.2015.
0.2
Promijenjeni nazivi poglavlja, raspisano poglavlje „O
oblikovnim obrascima“, dodane pripadajuće reference
Marijanović 21.09.2015.
0.3
Napisana poglavlja Strategija i Promatrač, dodana
tablica sa popisom slika, ažuriran Pojmovnik
0.4
Napisana poglavlja Stanje, Naredba i Jedini, ažuriran
Pojmovnik
0.5. Napisana poglavlja Adapter i Tvornica Marijanović 25.10.2015.
0.6. Napisan Zaključak i uređen Uvod Marijanović 25.10.2015.
0.7. Prilagođena forma seminara Marijanović 25.10.2015.
0.8. Ažuriran popis slikovnog materijala Marijanović 25.10.2015.
0.9. Ispravljene greške u seminaru Marijanović 25.10.2015.
1.0. Gotova prva verzija seminara Marijanović 25.10.2015.

Stranica 4 od 36
2. Opis seminarskog rada
Ovaj seminarski rad će pokriti općenite i najkorištenije oblikovne obrasce u programiranju
(Design Patterns). Cilj je što jednostavnije prikazati neke od tih oblikovnih obrazaca kako bi
se, navedeni, vrlo lako mogli početi koristiti u praksi. Programski jezik u kojem će biti
primjeri je Java.
Skup programera koji bi mogli biti zainteresirani za čitanje ovog seminarskog rada su svi
oni programeri koji programiraju u nekom objektno orijentiranom jeziku.

Stranica 5 od 36
3. Pojmovnik
Bug – Greška u izvornom kodu programa
Default – Podrazumijevano
Design Patterns – Oblikovni obrasci o kojima je ovaj seminar pisan
Flag – Zastavica, služi za označavanje stanja
Garbage collector – Oblik automatskog upravljanja memorijom
Java – Programski jezik
Output – Izlaz, tj. rezultat programa
Runtime – Program u trenutku izvođenja
Use case – Slučaj u kojem se nešto koristi

Stranica 6 od 36
4. Uvod
U programskom inženjerstvu, oblikovni obrazac je opće, ponovno upotrebljivo riješenje
za najčešće javljane probleme unutar određenog konteksta u softverskom dizajnu. Oblikovni
obrasci nisu gotovi dizajni koji se mogu pretvoriti u izvorni ili strojni kod. To je ideja ili
predložak za kako riješiti problem koji se može koristiti u mnogim različitim situacijama.
Oblikovni obrasci su formalizirane najbolje prakse koje se mogu koristiti za riješavanje
najčešćih problema pri izradi programa ili sustava.
Programsko inženjerstvo je teško iz više razloga, a neki od njih su:
 algoritamska sofisticiranost,
 postizanje adekvatne brzine izvođenja programa,
 ograničeni materijalni i vremenski resursi,
 složenost interakcije među komponentama programa
Oblikovni obrasci riješavaju problem složenosti interakcije među komponentama
programa, koji je složen iz više razloga. Postoji jako puno načina za organiziranje sustava, a
ponekad je i prekasno vidljiva prikladnost neke koncepcije programiranja (najčešće nakon
implementacije). Organiziranje interakcije među komponentama je ključni zadatak
programskog oblikovanja i zato koristimo oblikovne obrasce.
Korištenje oblikovnih obrazaca omogućuju da program korektno, sa zadovoljavajućim
perfomansama, obavlja svoj posao, a najbitnije od svega da je lako održiv i da je fleksibilan,
tj. otporan na promjene.
Oblikovni obrasci su stekli popularnost u računalnim znanostima nakon izlaska knjige
„Design Patterns: Elements of Reusable Object-Oriented Software“ (1994.). Iste godine
održala se prva konferencija „Patterns Languages of Programming“ , a sljedeće godine je
„Portland Pattern Repository“ odabran za dokumentiranje oblikovnih obrazaca.
Iako se oblikovni obrasci koriste u praksi već duže vrijeme, formalizacija koncepta je
zaostajala par godina.

Stranica 7 od 36
5. Obrazac Strategija (Strategypattern)
Obrazac Strategija je vjerovatno najkorišteniji oblikovni obrazac jer ga razni programeri
koriste, a da ni ne znaju da je on definiran kao oblikovni obrazac. On se koristi tako što se
definiraju različiti algoritmi, enkapsulira se svaki od njih i omogući se njihova lagana
zamjena. Koristi se u slučajevima kada više klasa mora imati nekakvo specifično ponašanje,
ali mogu imati svoju verziju implementacije tog ponašanja.
Možemo za primjer uzeti klasu Patka. Ta klasa je apstraktna i u njoj se nalazi sve što je
zajedničko svim patkama tj. što svaka patka mora imati da bi ona mogla biti patka. U njoj
smo naveli atribut NacinLeta odnosno metodu izvrsiLet koja izvršava nekakvu akciju na tom
atributu i jednu apstraktnu metodu „opis“:
1. Dijagram Strategije
Dakle, sada kada bilokoja klasa naslijedi klasu Patka, ona mora imati nekakav
NacinLeta, ali te implementacije mogu biti potpuno različite. U sljedećem primjeru smo
napravili klasu DivljaPatka, napisali njenu implementaciju metode opis i u konstruktor joj
postavili njenu implementaciju NacinLeta, a to je klasa DugiLet.

Stranica 8 od 36
2. Klasa DivljaPatka
U nastavku, uz pomoć StrategijaSimulatora možemo vidjeti kako koristiti oblikovni
obrazac strategiju i što nam to točno on omogućava i olakšava. Napravili smo objekt
divljaPatka i odmah pozvali metode opis i izvrsiLet, za sada znamo da se automatski u
konstruktoru po defaultu postavlja kao način leta DugiLet. Nakon toga smo uz pomoć metode
postaviNacinLeta postavili tom objektu KratkiLet kao NacinLeta, i opet pozvali metode opis
i izvrsiLet.
3. Simulator Strategije
Očekivani output programa je da u oba slučaja metoda opis vrati isti rezultat, a to je da
je poruka na ekranu „Ja sam divlja patka“, dok iako se zvala ista metoda izvrsiLet, očekuju se
dva različita rezultata zato što smo nakon prvog poziva metode promijenili atribut nacinLeta
iz DugiLet u KratkiLet. Kao što možemo vidjeti, i dobili smo taj output.

Stranica 9 od 36
4. Rezultat simulatora strategije
Zaključak je da, kao što je prikazano, razne implementacije nekih algoritama možemo
enkapsulirati u zasebne klase i mjenjati ih u runtime-u. Također, vrlo bitna prednost Strategija
obrasca, je ta da se za dodavanje novog načina leta ne treba mijenjati niti jedna druga klasa,
nego samo kreirati nova koja naslijeđuje apstraktnu klasu NacinLeta. Na taj način se
enkapsulacijom stvara više manjih i urednijih klasa kojih netreba izmjenjivati umjesto jedne
velike i nečitke u kojoj treba implementirati sve verzije algoritama. Upotrebom Strategija
oblikovnog obrasca uvelike se smanjuje mogućnost nastanka programske pogreške tj. bug-a,
ali u vremena koje je potrebno za pronaći isti ukoliko postoji.

Stranica 10 od 36
6. Obrazac Promatrač (Observerpattern)
Uzmimo za primjer da želimo isprogramirati program koji nam prikazuje trenutno
vrijeme na klijentu, bio on računalo ili mobilni uređaj. Trebali bi imati jednu verziju
aplikacije na klijentu koja bi služila za primanje informacija o vremenu i njegovo
prikazivanje, ali i neku serversku aplikaciju koja bi na svaku promjenu vremena poslala
svojim klijentima informacije o tom vremenu. Dolazimo do problema kako obavijestiti
klijenta da server ima nove informacije, tj. kako da server zna koje sve klijente treba
obavijestiti. Oblikovni obrazac Promatrač je stvoren za to i uz pomoć njega je takva
komunikacija izuzetno jednostavna za implementirati.
Imati ćemo dvije vrste sučelja:
1. Promatrač - što je u našem slučaju klijentska aplikacija, koja promatra i osluškuje
promjene na serveru
2. Subjekt – što je u našem slučaju serverska aplikacija, koja obaviještava svoje
promatrače kada je došlo do promjene informacija
5. Dijagram Promatrača
Dakle klasa koja naslijeđuje sučelje Subjekt ima listu klasa koje naslijeđuju sučelje
Promatrac. Uz pomoć metode registrirajPromatraca dodaju se promatrači koji žele biti
obaviješteni kada dođe do promjene informacija koje ih zanimaju. Uz pomoć metode
izbrisiPromatraca se ti promatrači brišu tj. subjekt više neće znati za njih i neće ih obavijestiti
kada dođe do novih informacija. Na kraju nam je ostala metoda obavijestiPromatrace koja
iterira po internoj listi promatrača od subjekta i na njima poziva metodu azuriraj tj.
obaviještava ih da je došlo do novih informacija i šalje im iste.

Stranica 11 od 36
U sljedećem primjeru možemo vidjeti kako koristiti oblikovni obrazac Promatrač.
Napravili smo instancu klase Server koja nasljeđuje sučelje Subjekt, instance klase Klijent_1 i
Klijent_2 koje obje naslijeđuju sučelje Promatrac i njima smo kao parametar u konstruktor
proslijedili različita imena kako bi u ispisu rezultata bilo jasnije što se događa. U objektu
server smo registrirali objekt klijent_1 kao promatrača i nakon toga smo promijenili poruku
na serveru, tj. simulirali smo dolazak novih informacija. U outputu vidimo da je klijent_1
automatski obaviješten, ali klijent_2 očekivano nije. U nastavku programa smo registrirali i
drugog klijenta, te nakon toga promijenili informacije na serveru i vidimo da su sada oboje
primili te promijenjene informacije. Za kraj smo izbrisali oba promatrača sa servera i ažurirali
podatke. Niti jedan od promatrača nije obaviješten o ažuriranim podatcima.
6. Simulator Promatrača
Ispis programa iz simulatora je točan i očekivan. U nastavku su još implementacije
nekih klasa kako bi bilo jasnije što, kako i zašto se dogodilo.
7. Rezultat Simulatora Promatrača

Stranica 12 od 36
Klase Klijent_1 i Klijent_2 imaju istu implementaciju pa je ovdje kao primjer
pokazana sam jedna. One služe samo da bi se potvrdilo da dvije različite klase mogu biti
promatrači, samo tako što implementiraju sučelje Promatrac. U metodi azuriraj se ispisuje
primljena poruka na konzolu.
8. Klasa Klijent_1
U klasi Server možemo primjetiti da smo u metodu setPoruka, nakon što se postavi nova
poruka, odmah pozvali metodu obavijestiPromatrace koja iterira po listi Promatraca i na
svima poziva metodu azuriraj, a kao parametar šalje novu poruku. Time smo dobili to da
svaki put kada dođe nova poruka na server se svi promatrači ažuriraju.
9. Klasa Server

Stranica 13 od 36
Zaključak je da oblikovni obrazac Promatrač definira vezu „jedan prema više“ između
objekata i da kada taj jedan objekt promijeni svoje stanje obavijesti svoje objekte koji su
vezani za njega o toj promjeni i oni automatski ažuriraju sve po potrebi. Subjekti ne znaju na
koji su način implementirani promatrači, a ni promatrači ne znaju na koji su način
implementirani subjekti i zbog toga možemo reći da je takav kod lakše čitati i ažurirati.

Stranica 14 od 36
7. Obrazac Stanje (State pattern)
Dobili smo zadatak isprogramirati program za automat sa lopticama. Glavni use case
aparata je: ubacite 5 kn, stisnete gumb, dobijete lopticu. Još se moraju podržavati slučajevi
kada nema više loptica i povrat novca.
Kada se malo bolje zadubimo u problematiku možemo vidjeti da zapravo postoje više
stanja automata, a to su:
 Nisu ubačeni novci
 Ubačeni su novci
 Nema više loptica
 Uspješna prodaja
Mogli bi definirati 4 konstante za svaki od stanja automata i onda pratiti u kojem je stanju
trenutno aparat i u metodi stisniGumb() to provjeravati sa if-else ili switch-case. Takav kod,
iako bi radio, ja jako nepregledan i kada bi htjeli dodati novo stanje automata onda bi to bilo
vrlo komplicirano i metode bi nam imale više stotina redaka.
Kako bi izbjegli takav kod i takav način rada, defnirati ćemo sučelje Stanje koje će imati
sve metode tj. podržavati će sve akcije koje se mogu pozvati/odraditi na automatu. Napraviti
ćemo 4 klase koje će implementirati to sučelje, a svaka od tih klasa će biti jedno stanje
automata.
10. Dijagram Stanja

Stranica 15 od 36
Za primjer, umjesto sve 4 klase prikazana je samo klasa ImaNovca zbog toga što su druge
tri vrlo slične. U njoj možemo vidjeti da ima refenencu na automat i da je se ona sama brine,
ovisno o pozvanoj metodi, da odradi željenu akciju i postavi sljedeće stanje na automat. I to
stanje ima svoje implementacije metoda. Na ovaj način smo odlično enkapsulirali način
različita ponašanja automata ovisno o stanju u kojem je i ne treba nam puno if-else funkcija
jer se svako stanje brine za sebe.
11. Klasa ImaNovca
Klasa Automat ima reference na sva stanja u kojima ona može biti i ima atribut
trenutnoStanje u koji sadrži referencu na trenutno stanje koje je postavljeno na automat i na
tom stanju se izvršavaju metode. Automat u runtime-u ne zna u kojem je stanju, ali ga nije ni
briga. On samo zna da se dogodila nekakva akcija, kao npr. gumb je stisnut, i onda on pozove
tu metodu na atributu trenutnoStanje i zna da svako stanje ima svoju implementaciju potrebne
metode.

Stranica 16 od 36
12. Klasa Automat
U simulatoru smo napravili instancu klase Automat i postavili u nju dvije loptice. Nakon
toga smo izvršili par naredbi na instanci. Nismo se morali brinuti o stanjima niti ništa
provjeravati. Za sve to se brine oblikovni obrazac Stanje. Prvo smo samo ubacili novac i
stisnuli gumb, te očekivano, dobili lopticu. Sada ima još samo jedna loptica u automatu.
Nakon toga smo ubacili novac, zatražili povrat i onda stisnuli gumb. Nismo dobili lopticu jer
je automat bio u stanju nemaNovca nakon što smo tražili povrat, još uvijek je jedna loptica
ostala. Ubacili smo ponovno novac i stisnuli gumb, nakon čega smo dobili lopticu i, pošto
više nema loptica, automat se je prebacio u nemaLoptica stanje. U tom stanju smo probali
izvršiti par naredbi, ali bez uspjeha.

Stranica 17 od 36
13. Simulator Stanja
Sve gore navedeno možemo vidjeti u outputu simulatora. Automat se sam brinuo o
stanjima u kojima je i uvijek je imao pravu akciju na svaku metodu.
14. Rezultat Simulatora Stanja

Stranica 18 od 36
Oblikovni obrazac Stanje omogućuje objektu da mijenja svoje ponašanje ovisno o
njegovom internom stanju. Korisnici tog objekta ne znaju da postoje njegova različita stanja,
oni samo pozivaju metode koje im trebaju, a objekt se brine da ih izvrši što bolje može. Kod
je puno čišći, pregledniji, čitljiviji i vrlo ga je lagano promijeniti. Ako trebamo promijeniti
ponašanje neke metode u nekom stanju, odmah znamo gdje to treba promijeniti. Također ako
trebamo izbacini neko stanje jednostavno pobrišemo njegovu referencu iz klase Automat, a
ako želimo dodati neko novo stanje, samo kreiramo novu klasu, implementiramo potrebno
sušelje, implementacije njegovih metoda i gotovi smo.

Stranica 19 od 36
8. Obrazac Naredba (Command pattern)
Programiramo upravljač za pametnu kuću. Sa tim upravljačem možemo upravljati
roletama, grijanjem, kućanskim aparatima i garažnim vratima. Dakle upravljač može
upravljati sa više različitih uređaja, ali na tim uređajima može imati samo dvije akcije, a to su
upali/ugasi. Naredbe se na upravljaču moraju moći mjenjati i u runtime-u. Znači brisati stare i
dodavati nove. Klase uređanja ne možemo mijenjati jer njih može napraviti njihov
proizvođač. Mi moramo imati samo neki jednostavan način za korištenje tih različitih klasa.
Kreirajmo instancu klase Svjetlo koje ima metode upali() i ugasi(). Napravili smo i sučelje
Naredba koje ima samo jednu metodu izvrsi(). Sada kako bi kreirali naredbu koja bi palila
svjetlo moramo napraviti novu klasu koja implementira sučelje Naredba. Nazovimo tu klasu
UpaliSvjetloNaredba. Ta klasa ima referencu na svjetlo koje pali i poziva na njemu tu
pripadajuću metodu. Na isti način smo napravili klase za gašenje svjetla, podizanje i spuštanje
garažnih vrata.
15. Dijagram Naredbe
Upravljaču smo u konstruktoru postavili da može primiti samo dvije naredbe, ali to je
proizvoljno. On ima metode za pozivanje naredbi ovisno o njihovom rednom broju, ali i za
njihovo postavljanje, odnosno micanje. Ima dvije odvojene liste. Jedna sadrži sve upali
naredbe, a druga sve ugasi. Postavljanje naredbi je napravljeno tako da se uvijek moraju
postaviti obje naredbe. Još uz sve to u klasi Upravljac postoji i intanca objekta
PraznaNaredba. Ona se postavlja po defaultu na sve pozicije u obje liste.

Stranica 20 od 36
16. Klasa Upravljac
Klasa PraznaNaredba je takozvani null objekt. On je koristan kada nemamo neki smislen
objekt za vratiti, ali ne želimo vratiti null vrijednost kako klijen nebi trebao paziti na to. U
našem slučaju je to prazna naredba koja, kada se pozove metoda izvrsi() na njoj, samo ispiše
da još niti jedna naredba nije dodijeljena tom rednom broju (iako zapravo ona je). Inače bi na
klijentu trebali provjeravati da li je vračen null i ako je onda to podržati. Ovako je kod na
klijentu puno čišći i pregledniji. Null objekti su široko korišteni i smatraju se dobrom
praksom. U metodi makniNaredbe() se može vidjeti da se zapravo me uklanjaju naredbe iz
lista nego se baš naš null objekt postavlja na tu poziciju umjesto prijašnjih naredbi.

Stranica 21 od 36
17. Simulator Naredba
U simulatoru napravimo instancu klase Upravljac i odmah nakon toga pozivamo
upali/ugasi metode na oba mjesta u upravljacu. U konstruktoru je postavljeno da ima samo
dva slobodna mjesta. Nakon toga kreiramo naredbe za upaliti/ugasiti svjetlo i dignuti/spustiti
garažna vrata. Naredbe za svjetlo postavljamo na prvu poziciju, a za garažna vrata na drugu.
Nakon toga opet pozivamo sve upali/ugasi metode. Za kraj digni/spusti naredbe postavljamo
na prvu poziciju (gdje su prije bile naredbe za upali/ugasi svjetlo), a naredbe na drugoj
poziciji uklanjamo. Zadnji puta pozivamo upali/ugasi metode na upravljaču. U nastavku
vidimo rezultat simulatora Naredba.

Stranica 22 od 36
18. Rezultat Simulatora Naredba
Kao što možemo primjetiti odmah nakon instanciranja klase Upravljac sve naredbe su
postavljene kao PrazneNaredbe. Nakon toga postavljamo naredbe za svjetlo i garazna vrata i
vidimo da nakon što ih pozovemo dobijemo očekivane rezultate. Moramo podržavati
mjenjanje naredbi u runtime-u, ali i njihovo uklanjanje, što vidimo u zadnjem primjeru da
radi. Ovdje su uzeti lagani primjeri gdje se naredba sastoji od samo jedne linije koda, npr.
upali svjetlo. Ali možemo kreirati puno kompleksnije naredbe, kao na primer za upravljanje
CD playerom. Na upravljaču možemo imati naredbu sviraj(), a u toj naredbi bi se na klasi
CDPlayer izvršile naredbe kao što su: upali(), postaviCD(), pokreni().
Oblikovni obrazac Naredba enkapsulira zahtjev u jedan zasebni objekt i sa time
omogućava parametriziranje drugih objekata sa različitim zahtjevima. Omogućuje i to da
klijent ne treba znati za implementacije klasa proizvođača, nego on zna samo da postoji klasa
koja radi željeni posao i da ta klasa sigurno ima metodu izvrsi() koju je naslijedila iz
kreiranog sučelja.

Stranica 23 od 36
9. Obrazac Jedini (Singleton pattern)
Kako bi rad sa nekim zahtjevnijim programima bio ugodan i brz koristi se više dretvi. Ali
prilikom korištenja više dretvi mogu se dogoditi razne greške. Na primjer možemo imati
jednu klasu koja će nam simulirati tvornicu čokolade. Ta klasa se spaja na prave uređaje u
tvornici. U tvornici sigurno postoje neki spremnici koji drže tu čokoladu i oni se prazne/pune
preko te klase. Pa tako se može dogoditi da jedna dretva ima svoju instancu klase Tvornica i
pozove funkciju koja će napuniti te spremnike do vrha, prije toga provjerava neki flag da li je
spremnik prazan koji je prilikom kreiranja instance klase postavljen na to da je spremnik
prazan. Kada završi sa punjenjem, postavi taj flag da je spremnik pun. Ali u međuvremenu,
druga dretva sa svojim instancom klase Tvornica isto poziva tu metodu punjenja spremnika, i
pošto je kreirala svoju instancu ona također misli da su spremnici prazni iako ih prva dretva
trenutno puni. Pa je i druga dretva počela sa punjenjem spremnika i došlo je do prepunjenja i
pucanja spremnika.
Kako bi se spriječili takvi problemi koristimo oblikovni obrazac jedini. U ovom slučaju
ćemo imati dva simulatora. Prvi simulator će simulirati korištenje dvije dretve bez korištenja
oblikovnog obrasca Jedini, a drugi sa korištenjem navedenog oblikovnog obrasca.
19. Klasa Tvornica
U klasi Tvornica imamo metodu napuniSpremnike() koja provjerava da li je punjenje
spremnika već u tijeku i ispisuje pripadajuću poruku. U konstruktor smo poslali jednu int
vrijednost koja nam samo služi za detaljniji ispis.

Stranica 24 od 36
20. Simulator bez oblikovnog obrasca Jedini
Simuliramo kreiranje prve instance klase Tvornica u prvoj dretvi. Nakon toga pozivamo dva
puta metodu napuniSpremnike(). U ovom slučaju je sve dobro. Prilikom prvog pozivanja se
spremnici počnu puniti, a kada se opet pozove ta metoda se ispiše da su spremnici već u
procesu punjenja. Ali problem nastupa kada simuliramo kreiranje druge instance klase
Tvornica sa drugom dretvom gdje opet pozivamo dva puta metodu napuniSpremnike().
21. Rezultat bez oblikovnog obrasca Jedini
Kao što vidimo bez problema smo ponovno pokrenuli proces punjenja spremnika iako je
proces već bio u tijeku i zbog tog propusta bi došlo do velikog i skupog oštećenja uređaja
tvornice.
U drugom simulatoru simuliramo korištenje oblikovnog obrasca Jedini. Da bi neka klasa
koristila taj oblikovni obrazac ona ne smije imati niti jedan javno dostupan konstruktor, tj.
mora imati privatne konstruktore. To bi spriječilo da bilo tko kreira instancu klase. Mora imati
i metodu koja, prvi put kada je pozvana, poziva taj privatni konstuktor i u atribute klase
postavi tu instancu. A svaki drugi put jednostavno vrati tu jednu i istu instancu klase. Taj
atribut je statičan tako da se ne moramo bojati da će nestati iz memorije.

Stranica 25 od 36
22. Klasa JedinaTvornica
U simulatoru kreiramo kreiranje instance klase uz pomoć metode novaInstanca(). Nakon
toga pozivamo sva puta metodu napuniSpremnike(). Kao i u prvom simulatoru, prvi put se
pokrene punjenje, a drugi put kaže da je punjenje u već tijeku. Nakon toga ponovo pozivamo
metodu novaInstanca() kako bi simulirali poziv iz druge dretve.
23. Simulator sa oblikovnim obrascem Jedini
Nakon što pozovemo metodu napuniSpremnike() na instanci iz druge dretve vidimo da,
iako smo zatražili novu instancu smo dobili staru koja je svjesna da je punjenje već u tijeku i
ne dozvoljava nam ponovno pokretanje punjenja i time smo riješili taj problem. Isto tako smo
mogli imati i više dretvi koje bi uvijek bile u toku sa stanjem tvornice.

Stranica 26 od 36
24. Rezultat sa oblikovnim obrascem Jedini
Oblikovni obrazac Jedini brine se da ta klasa ima samo jedu instancu i pruža njezinu
globalnu pristupnu metodu. Instanca je statična što znači da ju garbage collector, koji se brine
za čišćenje radne memorije od objekata koji se više ne koriste, neće uništiti. Sa privatnim
konstruktorom je postavila pravilo, da ako netko želi tu instancu klase mora pozvati metodu u
kojoj se provjerava da uvijek postoji samo jedna instanca.

Stranica 27 od 36
10. Obrazac Adapter (Adapter pattern)
Napravili smo program u dogovoru sa jednim proizvođačem garažnih vrata koji nam je
samo dao sučelja preko kojih komuniciramo, tj. šaljemo naredbe za otvaranje/zatvaranje vrata
itd. Naravno, nakon nekog vremena, uvijek mora doći do nekakve promjene. U ovom slučaju
promijenili smo proizvođača, a on za rad sa njegovim garažnim vratima nam daje totalno
nova sučelja, drugačija od prošlih.
25. Bez adaptera
Bez korištenja oblikovnog obrasca Adapter, trebali bismo proći kroz cijeli naš postojeći
program i izmjeniti kod kako bi radio sa novim sučeljima. To zahtjeva puno posla, a i otvara
mogućnost raznim bugovima. Kako bismo izbjegli pisanje koda u naš već postojeći sustav
koji provjereno radi, napisati ćemo samo adapter klasu i uz pomoć nje spojiti sustav u
cijelinu.
26. Sa adapterom
Postojeći program se nije promijenio, nova sučelja od proizvođača niti ne možemo
mjenjati. Napisali smo klasu Adapter koja nam je pomogla natrag spojiti te dvije komponente.
Važno je da adapter služi samo tome, delegiranju starih poziva metoda novima i
prilagođavanju podataka po potrebi.
Naš postojeći
program
Nova
sučelja
AdapterNaš postojeći
program
Nova
sučelja

Stranica 28 od 36
27. Dijagram Adaptera
Iz dijagrama vidimo da klijent još uvijek samo zna za StaroSucelje i nastavlja ga koristiti
kako ga je i koristio. Klasa Adapter je implementirala to staro sučelje, ali unutar
implementacije te metode ona poziva novu klasu, tj. novo sučelje. Klijent niti ne zna da je
došlo do promjene modela i sučelja i koristi sve kako je prije i koristio.
28. Klasa Adapter
Klasa Adapter implementira StaroSucelje, ali ima referencu na novu klasu NovaGaraza.
U metodama koje je nasljedila od starog sučelja prilagođava podatke za novu implementaciju
i poziva sve potrebne metode na novoj klasi da bi izvršila željenu akciju.

Stranica 29 od 36
29. Simulator Adapter
U simulatoru smo napravili instancu klase StaraGaraza koja predstavlja klasu starog
proizvođača, te instancu klase NovaGaraza koju smo dobili od novog proizvođača. Napravili
smo adapter u koji smo poslali novu implementaciju garaže, ali dobili staru implementaciju
sučelja. Dalje, pozvali smo metodu otvoriVrata() na starom objektu i istu tu metodu na
adapteru.
30. Rezultat Simulatora Adaptera
U outputu simulatora možemo vidjeti da, iako smo mi pozvali dva puta istu metodu
otvoriVrata(), dobili smo dva različita rezultata zbog toga što je prvi poziv metode bio na
starom objektu, a drugi na novom.
Oblikovni obrazac Adapter pretvara sučelje klase u drugačije sučelje, tj. ono sučelje koje
klijent očekuje i sa kojim zna raditi. Adapter omogućava klasama, koje inače nebi mogle
funkcionirati zajedno zbog različitih sučelja, da rade zajedno.

Stranica 30 od 36
11. Obrazac Tvornica (Factorypattern)
Uz pomoć oblikovnog obrasca Tvornica enkapsuliramo cijeli postupak kreiranja nekog
objeka i tako dobijemo čišći i uredniji kod, ali još bitnije je to što imamo kreaciju objekata na
jednom mjestu, pa tako ako ikad dođe do promjene kreacije te posebne instance klase, taj kod
promijenimo samo na jednom mjestu, a ne po cijelom kodu naše aplikacije.
31. Dijagram Tvornica
Iz dijagrama vidimo da klijent ne treba znati kako kreirati instancu klase Pizza, točnije ni
njenu implementaciju, već samo kaže tvornici koju vrstu želi i ona se brine da se u sučelje
instancira potrebna klasa i da se naprave svi potrebni koraci kreiranja objekta.
Tvornica ne vrača točnu implementaciju klase već implementaciju sučelja koje ima sve
potrebne metode za manipulaciju objektom. Klijent uz minimalno truda ili znanja o koracima
koji su potrebni kako bi kreirao tu instancu klase, dobije garantirano dobro kreirani objekt sa
jednom linijom koda.

Stranica 31 od 36
32. Klasa Tvornica Pizza
Klasa PizzaTvornica ima samo jednu metodu napraviPizzu() koja prima parametar ovisno
o tome koju pizzu želimo kreirati. Na osnovi tog parametra kreira željenu pizzu, a nakon toga
odradi dodatne korake koji su potrebni kako bi se pizza dobro napravila. U slučaju da se ikad
priprema pizze promijeni, mi trebamo samo ovdje ažurirati kod. Pa tako i ako dodamo novu
vrstu pizze ili maknemo staru, ovdje su sve promjene koje su potrebne. Tako smo smanjili
dupliciranje koda i mogućnost buga.
Bolje prakticiranje koda bi bilo da smo još napravili enum svih vrsta pizze koje možemo
kreirati umjesto da samo prosljeđujemo String, ali za demonstraciju oblikovnog obrasca nije
bilo potrebno pa je napravljeno da je što jednostavnije i lakše za razumjeti.

Stranica 32 od 36
33. Simulator Tvornica
U simulatoru prvo prikazujemo kako bi izgledalo kreiranje Pizza instanca klase bez
oblikovnog obrasca Tvornica. Kod je repetitivan i ima puno mjesta za napraviti grešku. Ako
ikad dođe do promjene izrade pizze trebamo na svakom ovom mjestu mjenjati i prilagođavati
taj kod, što iziskuje puno vremena i koncentracije.
U nastavku su napravljene dvije pizze sa oblikovnim obrascem Tvornica. Nakon potrebne
inicijalizacije tvornice, jednostavno pozivamo metodu napraviPizzu() i prosljeđujemo željenu
vrstu pizze. Kod od nekoliko linija smo sveli na svega jednu i uspješno enkapsulirali kreaciju
pizza objekata.

Stranica 33 od 36
34. Rezultat Simulatora Tvornice
U outputu vidimo da su odrađeni svi isti koraci kreiranja pizze i u jednom i u drugom
slučaju, ali u simulatoru vidimo da se je kod uvelike smanjio, te da je pregledniji, čišći i
najbitnije od svega lagano ga je promijeniti. Kod ovog oblikovnog obrasca je super to što
možemo imati više tvornica za jedan objekt, ako on zahtjeva različite pripreme i postupke
inicijalizacije.
Oblikovni obrazac Tvornica definira sučelje za kreaciju pojedinog objekta, ali omogućava
podklasama da odluče koju će klasu instancirati. Također nam omogućava laganu izmjenu
koda po potrebi, sve kreacije objekata držimo na jednom mjestu i s time smo izbacili
mogućnost krivog kreiranja objekta.

Stranica 34 od 36
12. Zaključak
Oblikovni obrasci nisu direktno riješenje nekog problema već su to načini kako što više
smanjiti mogućnost greške, omogućiti laganu nadogradnju ili izmjenu postojećeg
programskog koda, enkapsulirati sve zajedničke sposobnosti i osobine na jedno mjesto.
Oblikovni obrasci su riješenja problema u kontekstu, tj. oni su akumulirano znanje o čestim
problemima u programiranju.
U programiranju je repetitivnost i nečitki kod znak da bi implementacija i riješenje istog
problema bilo lakše i urednije sa nekim oblikovnim obracem. Oblikovne obrasce je relativno
lagano primijeniti, ali programer treba biti sposoban uočiti obrazac tamo gdje on prirodno
liježe. Također treba je bitno i vrijeme kada se uoči potreba za nekim oblikovnim obrascem.
Najčešće se uoči potreba kada se već napravi loša implementacija, što ne znači da je kasno, ali
otežava uvođenje specifičnog oblikovnog obrasca.
U ovom seminaru su svi oblikovni obrasci prikazani kroz programski jezik Java, zato što
je tako kod čitljiv i lako razumljiv, ali oni su primjenijivi na gotovo sve objektno orijentirane
jezike.

Stranica 35 od 36
13. Reference
1 https://www.fer.unizg.hr/predmet/ooup
2 https://en.wikipedia.org/wiki/Software_design_pattern
3 Head First Design Patterns, O'Reilly, 2004
4 https://sourcemaking.com/design_patterns
5 http://www.tutorialspoint.com/design_pattern/
6 http://www.oodesign.com/

Stranica 36 od 36
14. Popis slika
Str. Naziv slike
7 Dijagram Strategije
8 Klasa DivljaPatka, Simulator Strategije
9 Rezultat Simulatora Strategije
10 Dijagram Promatrača
11 Simulator Promatrača, Rezultat Simulatora Promatrača
12 Klasa Klijent_1, Klasa Server
14 Dijagram Stanja
15 Klasa ImaNovca
16 Klasa Automat
17 Simulator Stanja, Rezultat Simulatora Stanja
19 Dijagram Naredbe
20 Klasa Upravljac
21 Simulator Naredba
22 Rezultat Simulatora Naredba
23 Klasa Tvornica
24 Simulator bez oblikovnog obrasca Jedini, Rezultat bez oblikovnog obrasca Jedini
25 Klasa JedinaTvornica, Simulator sa oblikovnim obrascem Jedini
26 Rezultat sa oblikovnim obrascem Jedini
27 Bez Adaptera, Sa adapterom
28 Dijagram Adaptera, Klasa Adapter
29 Simulator Adapter, Rezultat Simulatora Adapter
30 Dijagram Tvornica
31 Klasa TvornicaPizza
32 Simulator Tvornica
33 Rezultat Simulatora Tvornica

Oblikovni obrasci

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (9)

Similar a Oblikovni obrasci

Similar a Oblikovni obrasci (20)

Oblikovni obrasci