Пројектни узорци

У софтверском инжењерству, пројектни узорак, шаблон или образац (енгл. design pattern) је опште, поново употребљиво решење за честе проблеме који се срећу приликом пројектовања софтвера. Пројектни узорак није готов дизајн који се може директно претворити у изворни код. Он служи само као опис или шаблон прилагођен да реши неки општији пројектни проблем у посебном контексту. Објектно оријентисани пројектни узорци су обично описи комуницирајућих објеката и класа, без одређивања конкретних класа и објеката.

Пројектни узорци припадају домену модула и веза између њих. На вишем нивоу су архитектурни узорци који су већи по опсегу, а обично описују општије обрасце који су везани за цео систем.

Нису сви софтверски узорци у исто време и пројектни узорци. На пример, алгоритми не решавају пројектне проблеме, већ само рачунарске проблеме.

Историјат

Узорци су првобитно настали као концепт у архитектури које је осмислио Кристофер Александер (1977-79). Године 1987, Кент Бек и Вард Канингем су почели да експериментишу са идејом примене узорака у програмирању и изнели су своје резултате исте године на OOPSLA конференцији. Наредних година су Бек, Канингем и остали наставили рад на узорцима.

Пројектни узорци су добили на популарности 1994. године, када је објављена књига Design Patterns: Elements of Reusable Object-Oriented Software коју су написали Ерих Гама, Ричард Хелм, Ралф Џонсон и Џон Влисајдс (познатији као „Gang of Four“ или често скраћено GoF). Те исте године је одржана и прва конференција о пројектним узорцима.

Пракса

Пројектни узорци могу да убрзају процес развоја софтвера тако што нуде тестиране и доказане парадигме развоја. Ефективно пројектовање софтвера захтева узимање у обзир проблема који нису видљиви све до касних фаза имплементације. Поново употребљиви пројектни узорци помажу да се избегну ситна проблематична питања која касније могу да изазову огромне проблеме, а побољшавају и читљивост изворног кôда оним програмерима који су већ упознати са пројектним узорцима.

Да би се повећала флексибилност, пројектни узорци често уводе додатни ниво комплексности, који у неким случајевима може да усложни дизајн и да чак утиче и на перформансе апликације.

По дефиниције, нови узорак се мора писати од почетка за сваку апликацију која га користи. Пошто неки аутори ово виде као корак уназад од поновне употребљивости компонената, истраживачи су радили на томе да претворе пројектне узорке у готове компоненте. Мејер и Арнаут тврде са имају успешност од 66% у претварању у компоненте најпознатијих узорака.

Често, људи само разумеју како да примене неки пројектни дизајн на одређени проблем. Овакве технике су тешко примењиве на шири скуп проблема. Пројктни узорци нуде општија решења, документовани на начин који не захтева везивање за специфичности одређеног проблема.

Структура

Пројектни узорци су састављени од неколико делова (погледати документацију испод). Најинтересантнији одељци су „Структура“, „Учесници“ и „Колаборација“. Ови одељци описују основну дизајнерску идеју: прототип микроархитектуре коју програмери копирају и прилагођавају њиховом дизајну да би решили проблем који се изнова понавља. Микроархитектура је скуп делова програма (класа, метода...) и веза између њих. Програмери искоришћавају пројектне узорке тако што у сопствени дизајн уводе ове прототипске микроархитектуре, што доводи до тога да њихове микроархитектуре дизајном почињу да личе на основну идеју пројектног узорка.

Поред овога, узорци омогућавају програмерима да комуницирају међусобно користећи имена која су већ увелико у употреби, разумевајући се лакше на тај начин. Основни пројектни узорци се временом могу побољшавати, чинећи их тако робуснијим од ad-hoc дизајна.

Доменски специфични узорци

Уложен је посебан труд да се направе пројектни узорци за одређене домене, укључујући и постојеће пројектне узорке, али и доменски специфичне пројектне узорке. Примери оваквих узорака су пројектни узорци корисничког сучеља , узорци визуелизације података и узорци у веб-дизајнирању .

Класификација и листа

Пројектни узорци су оригинално груписани у категорије: узорци креирања, узорци структуре и узорци понашања, а описани концептима делегирања, агрегације и консултације. Још једна класификација је увела и појам архитектурног узорка који се може применити на нивоу архитектуре система, а пример таквог узорка је Model-View-Controller узорак.

Име	Опис	У књизи Design Patterns	У књизи Code Complete
Узорци креирања
Уникат	Обезбеђује да класа има само једну инстанцу и даје глобални приступ тој инстанци.	Да	Да
Прототип	Специфицира врсте објеката који се креирају коришћењем прототипске инстанце и креира нове објекте копирањем прототипа.	Да	Не
Фабрички метод	Дефинише интерфејс за креирање објеката, али оставља поткласама да одлуче чије објекте креирају. Узорак допушта класи да делегира стварање објекта поткласи.	Да	Да
Апстрактна фабрика	Обезбеђује интерфејс за креирање фамилија повезаних или зависних објеката без специфицирања конкретних класа фамилије објеката.	Да	Да
Градитељ	Раздваја конструкцију комплексног објекта од његове репрезентације тако да исти процес може да креира различите репорезентације.	Да	Не
Лења иницијализација	Тактички одлаже стварање објекта, израчунавање неке вредности или други скуп процес док он први пут не буде потребан.	Не	Не
Пул конекција	Избегава скупе операције вишеструког конектовања и дисконектовања.	?	?
Пул објеката	Избегава скупа дохватања и отпуштања ресурса поново употребљавајући објекте који се више не користе.	Не	Не
Узорци структуре
Композиција	Компонује објекте у структуру стабла (хијерархија целина-део). Композиција омогућава клијентима да униформно третирају и индивидуалне објекте и њихове композиције.	Да	Да
Декоратер	Динамички додаје могућности неком објекту. Декоратер представља флексибилну алтернативу извођењу за проширивање функционалности.	Да	Да
Мува	Дељење малих објеката (објеката без стања) да би се избегла хиперпродукција објеката.	Да	Не
Адаптер	Конвертује интерфејс класе у други интерфејс који клијенти очекују. Адаптер омогућава рад заједно класа које иначе то не би могле због различитог интерфејса.	Да	Да
Фасада	Пружа јединствен интерфејс скупу различитих интерфејса неког подсистема. Фасада дефинише интерфејс вишег нивоа да би се подсистем лакше користио.	Да	Да
Прокси	Реализује замену (сурогат) другог објекта који контролише приступ оригиналном објекту.	Да	Не
Мост	Раздваја апстракцију од њене имплементације да би се могле независно мењати.	Да	Да
Узорци понашања
Посматрач	Дефинише зависност 1:N између објеката, такву да када један објекат промени стање сви зависни објекти буду обавештени и аутоматски се ажурирају.	Да	Да
Итератор	Обезбеђује секвенцијални приступ елементима неког агрегатног објекта без експонирања унутрашње структуре тог агрегата.	Да	Да
Стратегија	Дефинише фамилију алгоритама, енкапсулирајући сваки и чини их међусобно замењивим. Стратегија омогућава једноставну промена алгоритма у време извршења.	Да	Да
Шаблонски метод	Дефинише костур неког операционог алгоритма, делегирајући поједине кораке поткласама. Шаблонски метод омогућава поткласама да редефинишу одређене кораке алгоритма без измене његове структуре.	Да	Да
Стање	Омогућава објекту да мења своје понашање када се мења његово унутрашње стање. Изгледа када да објекат мења своју класу.	Да	Не
Подсетник	Без нарушавања енкапсулације снима и екстернализује стање неког објекат, тако да омогући да се објекат касније може вратити у дато стање.	Да	Не
Посредник	Дефинише објекат који енкапсулира како скуп објеката интерагује. Посредник омогућава слабо спрезање објеката што постиже чувањем објеката који се међусобно реферишу, а то дозвољава да им се интеракција мења независно.	Да	Не
Команда	Енкапсулира захтев у један објекат, омогућавајући да се клијенти параметризују различитим захтевима, да се захтеви испоручују кроз ред чекања, да се прави дневник захтева и да се ефекти извршеног захтева пониште.	Да	Не
Ланац одговорности	Избегава непосредно везивање пошиљаоца захтева са примаоцем захтева, дајући шансу већем броју објеката да обраде захтев. Ланац одговорности повезује објекте примаоце захтева у ланац и прослеђује захтев низ ланац док га неки објекат не обради.	Да	Не
Посетилац	Репрезентује једну операцију коју треба применити на елементе једне објектне структуре. Посетилац омогућава дефинисање нове операције без измене класа елемената над којим се извршава.	Да	Не
Интерпретер	За дати језик дефинише репрезентацију његове граматике, као и интерпетер који користи ту репрезентацију да интерпретира исказе језика.	Да	Не

Документација

Документација пројектног узорка описује контекст у коме се узорак користи, проблематику које узорак треба да реши и предложено решење. Не постоји један стандардни формат за документовање пројектних узорака. Штавише, постоји доста различитих формата које су користили различити аутори узорака. Ипак, према Мартину Фаулеру, неке форме за описивање пројектних узорака су постале познатије од других, а самим тим и постале основа за описивање нових пројектних узорака. Један од чешће коришћених формата документације је онај који су користили Ерих Гама и остали („Gang of Four“) при писању књиге „Design Patterns“. Тај формат садржи следеће одељке:

• Име узорка и класификација: Јединствено описно име узорка које служи да се он идентификује.
• Намера: Опис циља који стоји иза узорка и разлози за његово коришћење.
• Познат и као: Остала имена узорка.
• Мотивација: Опис проблема и контекст где је узорак применљив.
• Применљивост: Ситуације у којима је узорак применљив; контекст узорка.
• Структура: Графичка представа узорка. У ову сврху се могу користити дијаграми класа и/или остали дијаграми.
• Учесници: Списак класа и објеката коришћених у узорку и њихових улога у дизајну.
• Колаборација: Опис како класе и објекти коришћени у узорку комуницирају међусобно.
• Консеквенце: Опис резултата и последица примене узорка, као и разумевање цене и добити примене узорка.
• Имплементација: Опис имплементације узорка.
• Примери кôда: Илустративни пример како се узорак може употребити у изворном кôду.
• Примери употреба: Примери употреба узорка из стварног живота.
• Повезани или слични узорци: Остали узорци који су на неки начин у вези са овим узорком. Дискусија између овог и осталих сличних узорака.

Литература

• 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 (мај 2003). Core J2EE Patterns: Best Practices and Design Strategies (2nd Edition). Prentice Hall. ISBN 978-0-13-142246-9. 
• Beck, Kent (октобар 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. (март 1996). Proceedings of the 18th International Conference on Software Engineering. стр. 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. стр. 235. ISBN 978-0-19-512123-0. Архивирано из оригинала (PDF) 1. 8. 2003. г. 
• 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. Архивирано из оригинала 17. 6. 2007. г.