Projektni uzorci

U softverskom inženjerstvu, projektni uzorak, šablon ili obrazac (engl. design pattern) je opšte, ponovo upotrebljivo rešenje za česte probleme koji se sreću prilikom projektovanja softvera. Projektni uzorak nije gotov dizajn koji se može direktno pretvoriti u izvorni kod. On služi samo kao opis ili šablon prilagođen da reši neki opštiji projektni problem u posebnom kontekstu. Objektno orijentisani projektni uzorci su obično opisi komunicirajućih objekata i klasa, bez određivanja konkretnih klasa i objekata.

Projektni uzorci pripadaju domenu modula i veza između njih. Na višem nivou su arhitekturni uzorci koji su veći po opsegu, a obično opisuju opštije obrasce koji su vezani za ceo sistem.

Nisu svi softverski uzorci u isto vreme i projektni uzorci. Na primer, algoritmi ne rešavaju projektne probleme, već samo računarske probleme.

Istorijat

Uzorci su prvobitno nastali kao koncept u arhitekturi koje je osmislio Kristofer Aleksander (1977-79). Godine 1987, Kent Bek i Vard Kaningem su počeli da eksperimentišu sa idejom primene uzoraka u programiranju i izneli su svoje rezultate iste godine na OOPSLA konferenciji. Narednih godina su Bek, Kaningem i ostali nastavili rad na uzorcima.

Projektni uzorci su dobili na popularnosti 1994. godine, kada je objavljena knjiga Design Patterns: Elements of Reusable Object-Oriented Software koju su napisali Erih Gama, Ričard Helm, Ralf Džonson i Džon Vlisajds (poznatiji kao „Gang of Four“ ili često skraćeno GoF). Te iste godine je održana i prva konferencija o projektnim uzorcima.

Praksa

Projektni uzorci mogu da ubrzaju proces razvoja softvera tako što nude testirane i dokazane paradigme razvoja. Efektivno projektovanje softvera zahteva uzimanje u obzir problema koji nisu vidljivi sve do kasnih faza implementacije. Ponovo upotrebljivi projektni uzorci pomažu da se izbegnu sitna problematična pitanja koja kasnije mogu da izazovu ogromne probleme, a poboljšavaju i čitljivost izvornog kôda onim programerima koji su već upoznati sa projektnim uzorcima.

Da bi se povećala fleksibilnost, projektni uzorci često uvode dodatni nivo kompleksnosti, koji u nekim slučajevima može da usložni dizajn i da čak utiče i na performanse aplikacije.

Po definicije, novi uzorak se mora pisati od početka za svaku aplikaciju koja ga koristi. Pošto neki autori ovo vide kao korak unazad od ponovne upotrebljivosti komponenata, istraživači su radili na tome da pretvore projektne uzorke u gotove komponente. Mejer i Arnaut tvrde sa imaju uspešnost od 66% u pretvaranju u komponente najpoznatijih uzoraka.

Često, ljudi samo razumeju kako da primene neki projektni dizajn na određeni problem. Ovakve tehnike su teško primenjive na širi skup problema. Projktni uzorci nude opštija rešenja, dokumentovani na način koji ne zahteva vezivanje za specifičnosti određenog problema.

Struktura

Projektni uzorci su sastavljeni od nekoliko delova (pogledati dokumentaciju ispod). Najinteresantniji odeljci su „Struktura“, „Učesnici“ i „Kolaboracija“. Ovi odeljci opisuju osnovnu dizajnersku ideju: prototip mikroarhitekture koju programeri kopiraju i prilagođavaju njihovom dizajnu da bi rešili problem koji se iznova ponavlja. Mikroarhitektura je skup delova programa (klasa, metoda...) i veza između njih. Programeri iskorišćavaju projektne uzorke tako što u sopstveni dizajn uvode ove prototipske mikroarhitekture, što dovodi do toga da njihove mikroarhitekture dizajnom počinju da liče na osnovnu ideju projektnog uzorka.

Pored ovoga, uzorci omogućavaju programerima da komuniciraju međusobno koristeći imena koja su već uveliko u upotrebi, razumevajući se lakše na taj način. Osnovni projektni uzorci se vremenom mogu poboljšavati, čineći ih tako robusnijim od ad-hoc dizajna.

Domenski specifični uzorci

Uložen je poseban trud da se naprave projektni uzorci za određene domene, uključujući i postojeće projektne uzorke, ali i domenski specifične projektne uzorke. Primeri ovakvih uzoraka su projektni uzorci korisničkog sučelja , uzorci vizuelizacije podataka i uzorci u veb-dizajniranju .

Klasifikacija i lista

Projektni uzorci su originalno grupisani u kategorije: uzorci kreiranja, uzorci strukture i uzorci ponašanja, a opisani konceptima delegiranja, agregacije i konsultacije. Još jedna klasifikacija je uvela i pojam arhitekturnog uzorka koji se može primeniti na nivou arhitekture sistema, a primer takvog uzorka je Model-View-Controller uzorak.

Ime	Opis	U knjizi Design Patterns	U knjizi Code Complete
Uzorci kreiranja
Unikat	Obezbeđuje da klasa ima samo jednu instancu i daje globalni pristup toj instanci.	Da	Da
Prototip	Specificira vrste objekata koji se kreiraju korišćenjem prototipske instance i kreira nove objekte kopiranjem prototipa.	Da	Ne
Fabrički metod	Definiše interfejs za kreiranje objekata, ali ostavlja potklasama da odluče čije objekte kreiraju. Uzorak dopušta klasi da delegira stvaranje objekta potklasi.	Da	Da
Apstraktna fabrika	Obezbeđuje interfejs za kreiranje familija povezanih ili zavisnih objekata bez specificiranja konkretnih klasa familije objekata.	Da	Da
Graditelj	Razdvaja konstrukciju kompleksnog objekta od njegove reprezentacije tako da isti proces može da kreira različite reporezentacije.	Da	Ne
Lenja inicijalizacija	Taktički odlaže stvaranje objekta, izračunavanje neke vrednosti ili drugi skup proces dok on prvi put ne bude potreban.	Ne	Ne
Pul konekcija	Izbegava skupe operacije višestrukog konektovanja i diskonektovanja.	?	?
Pul objekata	Izbegava skupa dohvatanja i otpuštanja resursa ponovo upotrebljavajući objekte koji se više ne koriste.	Ne	Ne
Uzorci strukture
Kompozicija	Komponuje objekte u strukturu stabla (hijerarhija celina-deo). Kompozicija omogućava klijentima da uniformno tretiraju i individualne objekte i njihove kompozicije.	Da	Da
Dekorater	Dinamički dodaje mogućnosti nekom objektu. Dekorater predstavlja fleksibilnu alternativu izvođenju za proširivanje funkcionalnosti.	Da	Da
Muva	Deljenje malih objekata (objekata bez stanja) da bi se izbegla hiperprodukcija objekata.	Da	Ne
Adapter	Konvertuje interfejs klase u drugi interfejs koji klijenti očekuju. Adapter omogućava rad zajedno klasa koje inače to ne bi mogle zbog različitog interfejsa.	Da	Da
Fasada	Pruža jedinstven interfejs skupu različitih interfejsa nekog podsistema. Fasada definiše interfejs višeg nivoa da bi se podsistem lakše koristio.	Da	Da
Proksi	Realizuje zamenu (surogat) drugog objekta koji kontroliše pristup originalnom objektu.	Da	Ne
Most	Razdvaja apstrakciju od njene implementacije da bi se mogle nezavisno menjati.	Da	Da
Uzorci ponašanja
Posmatrač	Definiše zavisnost 1:N između objekata, takvu da kada jedan objekat promeni stanje svi zavisni objekti budu obavešteni i automatski se ažuriraju.	Da	Da
Iterator	Obezbeđuje sekvencijalni pristup elementima nekog agregatnog objekta bez eksponiranja unutrašnje strukture tog agregata.	Da	Da
Strategija	Definiše familiju algoritama, enkapsulirajući svaki i čini ih međusobno zamenjivim. Strategija omogućava jednostavnu promena algoritma u vreme izvršenja.	Da	Da
Šablonski metod	Definiše kostur nekog operacionog algoritma, delegirajući pojedine korake potklasama. Šablonski metod omogućava potklasama da redefinišu određene korake algoritma bez izmene njegove strukture.	Da	Da
Stanje	Omogućava objektu da menja svoje ponašanje kada se menja njegovo unutrašnje stanje. Izgleda kada da objekat menja svoju klasu.	Da	Ne
Podsetnik	Bez narušavanja enkapsulacije snima i eksternalizuje stanje nekog objekat, tako da omogući da se objekat kasnije može vratiti u dato stanje.	Da	Ne
Posrednik	Definiše objekat koji enkapsulira kako skup objekata interaguje. Posrednik omogućava slabo sprezanje objekata što postiže čuvanjem objekata koji se međusobno referišu, a to dozvoljava da im se interakcija menja nezavisno.	Da	Ne
Komanda	Enkapsulira zahtev u jedan objekat, omogućavajući da se klijenti parametrizuju različitim zahtevima, da se zahtevi isporučuju kroz red čekanja, da se pravi dnevnik zahteva i da se efekti izvršenog zahteva ponište.	Da	Ne
Lanac odgovornosti	Izbegava neposredno vezivanje pošiljaoca zahteva sa primaocem zahteva, dajući šansu većem broju objekata da obrade zahtev. Lanac odgovornosti povezuje objekte primaoce zahteva u lanac i prosleđuje zahtev niz lanac dok ga neki objekat ne obradi.	Da	Ne
Posetilac	Reprezentuje jednu operaciju koju treba primeniti na elemente jedne objektne strukture. Posetilac omogućava definisanje nove operacije bez izmene klasa elemenata nad kojim se izvršava.	Da	Ne
Interpreter	Za dati jezik definiše reprezentaciju njegove gramatike, kao i interpeter koji koristi tu reprezentaciju da interpretira iskaze jezika.	Da	Ne

Dokumentacija

Dokumentacija projektnog uzorka opisuje kontekst u kome se uzorak koristi, problematiku koje uzorak treba da reši i predloženo rešenje. Ne postoji jedan standardni format za dokumentovanje projektnih uzoraka. Štaviše, postoji dosta različitih formata koje su koristili različiti autori uzoraka. Ipak, prema Martinu Fauleru, neke forme za opisivanje projektnih uzoraka su postale poznatije od drugih, a samim tim i postale osnova za opisivanje novih projektnih uzoraka. Jedan od češće korišćenih formata dokumentacije je onaj koji su koristili Erih Gama i ostali („Gang of Four“) pri pisanju knjige „Design Patterns“. Taj format sadrži sledeće odeljke:

• Ime uzorka i klasifikacija: Jedinstveno opisno ime uzorka koje služi da se on identifikuje.
• Namera: Opis cilja koji stoji iza uzorka i razlozi za njegovo korišćenje.
• Poznat i kao: Ostala imena uzorka.
• Motivacija: Opis problema i kontekst gde je uzorak primenljiv.
• Primenljivost: Situacije u kojima je uzorak primenljiv; kontekst uzorka.
• Struktura: Grafička predstava uzorka. U ovu svrhu se mogu koristiti dijagrami klasa i/ili ostali dijagrami.
• Učesnici: Spisak klasa i objekata korišćenih u uzorku i njihovih uloga u dizajnu.
• Kolaboracija: Opis kako klase i objekti korišćeni u uzorku komuniciraju međusobno.
• Konsekvence: Opis rezultata i posledica primene uzorka, kao i razumevanje cene i dobiti primene uzorka.
• Implementacija: Opis implementacije uzorka.
• Primeri kôda: Ilustrativni primer kako se uzorak može upotrebiti u izvornom kôdu.
• Primeri upotreba: Primeri upotreba uzorka iz stvarnog života.
• Povezani ili slični uzorci: Ostali uzorci koji su na neki način u vezi sa ovim uzorkom. Diskusija između ovog i ostalih sličnih uzoraka.

Literatura

• Alexander, Christopher; Ishikawa, Sara; Silverstein, Murray; Jacobson, Max; Fiksdahl-King, Ingrid; Angel, Shlomo (1977). A Pattern Language: Towns, Buildings, Construction. New York: Oxford University Press. ISBN 978-0-19-501919-3. 
• Alur, Deepak; Crupi, John; Malks, Dan (maj 2003). Core J2EE Patterns: Best Practices and Design Strategies (2nd Edition). Prentice Hall. ISBN 978-0-13-142246-9. 
• Beck, Kent (oktobar 2007). Implementation Patterns. Addison-Wesley. ISBN 978-0-321-41309-3. 
• Beck, Kent; Crocker, R.; Meszaros, G.; Coplien, J. O.; Dominick, L.; Paulisch, F.; Vlissides, J. (mart 1996). Proceedings of the 18th International Conference on Software Engineering. str. 25—30. 
• Borchers, Jan (2001). A Pattern Approach to Interaction Design. John Wiley & Sons. ISBN 978-0-471-49828-5. 
• Coplien, James O.; Schmidt, Douglas C. (1995). Pattern Languages of Program Design. Addison-Wesley. ISBN 978-0-201-60734-5. 
• Coplien, James O.; Vlissides, John M.; Kerth, Norman L. (1996). Pattern Languages of Program Design 2. Addison-Wesley. ISBN 978-0-201-89527-8. 
• Eloranta, Veli-Pekka; Koskinen, Johannes; Leppänen, Marko; Reijonen, Ville (2014). Designing Distributed Control Systems: A Pattern Language Approach. Wiley. ISBN 978-1118694152. 
• Fowler, Martin (1997). Analysis Patterns: Reusable Object Models. Addison-Wesley. ISBN 978-0-201-89542-1. 
• Fowler, Martin (2003). Patterns of Enterprise Application Architecture. Addison-Wesley. ISBN 978-0-321-12742-6. 
• Freeman, Eric; Freeman, Elisabeth; Sierra, Kathy; Bates, Bert (2004). Head First Design Patterns. O'Reilly Media. ISBN 978-0-596-00712-6. 
• Hohmann, Luke; Fowler, Martin; Kawasaki, Guy (2003). Beyond Software Architecture. Addison-Wesley. ISBN 978-0-201-77594-5. 
• Gabriel, Richard (1996). Patterns of Software: Tales From The Software Community (PDF). Oxford University Press. str. 235. ISBN 978-0-19-512123-0. Arhivirano iz originala (PDF) 1. 8. 2003. g. 
• Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. ISBN 978-0-201-63361-0. 
• Hohpe, Gregor; Woolf, Bobby (2003). Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley. ISBN 978-0-321-20068-6. 
• Holub, Allen (2004). Holub on Patterns. Apress. ISBN 978-1-59059-388-2. 
• Kircher, Michael; Völter, Markus; Zdun, Uwe (2005). Remoting Patterns: Foundations of Enterprise, Internet and Realtime Distributed Object Middleware. John Wiley & Sons. ISBN 978-0-470-85662-8. 
• Larman, Craig (2005). Applying UML and Patterns. Prentice Hall. ISBN 978-0-13-148906-6. 
• Liskov, Barbara; Guttag, John (2000). Program Development in Java: Abstraction, Specification, and Object-Oriented Design. Addison-Wesley. ISBN 978-0-201-65768-5. 
• Manolescu, Dragos; Voelter, Markus; Noble, James (2006). Pattern Languages of Program Design 5. Addison-Wesley. ISBN 978-0-321-32194-7. 
• Marinescu, Floyd (2002). EJB Design Patterns: Advanced Patterns, Processes and Idioms. John Wiley & Sons. ISBN 978-0-471-20831-0. 
• Martin, Robert Cecil; Riehle, Dirk; Buschmann, Frank (1997). Pattern Languages of Program Design 3. Addison-Wesley. ISBN 978-0-201-31011-5. 
• Mattson, Timothy G; Sanders, Beverly A.; Massingill, Berna L. (2005). Patterns for Parallel Programming. Addison-Wesley. ISBN 978-0-321-22811-6. 
• Shalloway, Alan; Trott, James R. (2001). Design Patterns Explained, Second Edition: A New Perspective on Object-Oriented Design. Addison-Wesley. ISBN 978-0-321-24714-8. 
• Vlissides, John M. (1998). Pattern Hatching: Design Patterns Applied. Addison-Wesley. ISBN 978-0-201-43293-0. 
• Weir, Charles; Noble, James (2000). Small Memory Software: Patterns for systems with limited memory. Addison-Wesley. ISBN 978-0-201-59607-6. Arhivirano iz originala 17. 6. 2007. g.