Elektronski fakultet Niš
Katedra za Računarstvo
S T R A T E G Y
O B R A Z A C
Predmet:
Projektni obrasci
Student
Mentor
Aleksandar Stanković Prof.dr Dejan Rančić
Br. Indeksa: 11891
1
SADRŽAJ
1. Uvod
Strana 2
2. Obrazac Strategy
Strana 2
3. Ključne karakteristike obrasca Strategy
Strana 2
4. Rešavanje praktičnih problema uz pomoć
obrasca Strategy
Strana 4
4.1Pristup obradi novih zahteva
Strana 4
4.2 Početni zahtevi primera elektronske prodaje
Strana 5
4.3 Obrada novih zahteva
Strana 6
5. Upotreba obrasca Strategy
Strana 9
6.Primeri kodova u različitim programskim jezicima
Strana 10
6.1 Primer koda u jeziku C#
Strana 10
6.2 Primer iz stvarnog sveta
Strana 12
6.3 Primer koda u jeziku Java
Strana 14
7. Zaključak
Strana 15
8. Literatura
Strana 15
3
Učesnici i
- Klasa
Strategy
odreĎuje kako se koriste različiti algoritmi.
saradnici:
- Klasa
ConcreteStrategy
realizuju različite algoritme.
-
Klasa
Context
koristi specifičnu klasu
ConcreteStrategy
pomoću
reference tipa
Strategy
. Klase
Strategy
i
Context
zajedno realizuju
izabrani algoritam.
Context
prosleĎuje zahteve klijenta klasi
Strategy
.
Posledice:
- Obrazac Strategy odreĎuje porodicu algoritma.
-
Strukture switch i/ili uslovi mogu se eliminisati.
-
Morate koristiti sve algoritme na isti način (svi moraju imati isti interfejs).
Interakcija izmeĎu klasa
ConcreteStrategies
i
Context
može
zahtevati dodavanje pristupnih metoda klasi
Context
.
Realizacija
:
Neka klasa koja koristi algoritam (
Context
) sadrži objekat apstraktne klase
(
Strategy
) čija apstraktna metoda odreĎuje kako se koristi algoritam. Svaka
izvedena klasa realizuje odgovarajući algoritam. Napomena: ta metoda ne bi
bila apstraktna ako postoji podrazumevano ponašanje.U prototipu obrasca
Strategy, klijent je odgovoran za izbor odreĎene realizacije i prenosi je
kontekstu obrasca.
Slika 1. – Standardan, pojednostavljen prikaz obrasca Strategy.
4
4.
Rešavanje praktičnih problema uz
pomoć Strategy obrasca
U ovom primeru počinjemo da proučavamo nov praktičan primer elektronske prodaje
(prodaje preko Interneta). TakoĎe, počinjemo da rešavamo probleme pomoću obrasca
Strategy.
4.1 Pristup obradi novih zahteva
U životu, a i u softverskim aplikacijama, često moramo da odlučujemo koji je pristup
izvršenju zadataka ili rešavanju problema odgovarajući. Većina nas je naučila da je biranje
najkraćeg puta, na kratke staze, može dovesti do ozbiljnih dugoročnih problema. Na primer,
svi moraju da zamene ulje u automobilu posle odreĎenog broja preĎenih kilometara. Možda
ne menjam ulje svakih 5000 kilometara, ali neću čekati ni 50000 (ako bih to učinio, ne bi bilo
potrebe da ikad više menjam ulje: auto ne bi radio). Posmatrajmo pisaći sto – mnogi od nas
odlažu na njega svakojake dokumente. To funkcioniše dobro na kratke staze, ali dugoročno,
sve je teže snaći se meĎu gomilom papira koja raste. Nevolje često nastupaju na duge staze
usled neoptimalnih kratkoročnih rešenja.
Nažalost, mnogi programeri još nisu naučili te lekcije. U mnogim projektima pažnja se
obraća samo na hitne, goruće potrebe, i ne razmišlja se o budućem održavanju. Postoji
nekoliko razloga zbog kojih se u projektima zanemaruju dugoročna pitanja, kao što su lakoća
održavanja ili mogućnost menjanja. Česti izgovori su:
'' Zaista ne možemo da predvidimo kako će se zahtevi menjati.''
'' Ako pokušamo da shvatimo kako će se stvari menjati, ostaćemo zauvek na analizi.''
''Ako pokušamo da pišemo program kojem možemo dodati novu funkcionalnost,
ostaćemo zauvek na projektovanju.''
''Nemamo ni vremena ni novca za to.''
Čini se da je izbor:
Preterati sa analiziranjem ili projektovanjem – to nazivamo ''paraliza analizom''.
Počnimo da, pišemo kod ne obazirući se na dugoročna pitanja, a zatim preĎimo na
drugi projekat pre nego što ta kratkovidost izazove previše problema. To nazivamo:
'' napustite brod (odmah po isporučivanju)! ''
Pošto je uprava programerskih odeljenja pod pritiskom da isporuči program, a ne da
ga održava, možda ti rezultati i nisu iznenaĎujući. MeĎutim, ako se za trenutak zamislimo,
postaje očigledno da sistem razmišljanja sprečava mnoge programere da vide druge opcije –
oni smatraju da je projektovanje koje omogućava promene skuplje od projektovanja koje
promene zanemaruje.
