Програмски оквир

Из Википедије, слободне енциклопедије

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

Оквири садрже кључно препознатљиве могућности које их одвајају од нормалних библиотека:

  • Инверзија контроле: У оквиру, за разлику од библиотека или нормалних апликација корисника, свеобухватно програмско управљање током није наређивано од стране саговорника, већ од стране оквира.[1]
  • подразумевано понашање: Оквир има подразумевано понашање. Ово подразумевано понашање мора бити неко корисно понашање а не скуп бескорисних потпрограма.
  • растегљивост: Оквир може бити проширен од стране корисника обично селективним обарањем или специјализованим кодом корисника да омогући специфичне функционалности.
  • непроменљиви код оквира: Код оквира, генерално, не треба мењати, прихватајући екстензије од стране корисника. Другим речима, корисници могу проширити оквир, али не треба мењати његов код.

Образложење[уреди]

Дизајнери програмских оквира циљају да олакшају софтверски развој омогућавајући дизајнерима и програмерима да одвоје своје време на упознавање софтверских захтева уместо на детаље вишестандардног нижег нивоа које доприносе систем који ради, и тиме смањујући свеобухватно време развоја.[2] На пример, тим који користи оквир веб прилога да направи банкарски веб сајт се може фокусирати на писање кода који се посебно односи на банкарство уместо на механику захтева и управљања.

Оквири често додају величини програма, феномен назван "code bloat". Звог апликацијских захтева корисника, и такмичарски и комплементарни оквири понекад се појаве заједно у производу. Даље, звог комплексности АПИ-а, намењено смањење у свеовухватном времену развоја можда не може бити постигнуто због потребе за додатним временом на учење коришћења оквира; ова критика је очито валидна када посебни или нови оквир је први пут сусретнут од стране развојног тима. Ако се такав оквир не искористи у следећим задацима посла, уложено време у учењу оквира може коштати више него код који је посебно написан, а познат пројектном тиму; многи програмери чувају копије корисног boilerplate-а за честе потребе.

Какогод, када се оквир коначно научи, будући пројекти могу бити брже и лакше завршени; концепт оквира је да се направи скуп једна-величина-која-одговара-свима решења, и са присношћу, производња кода би логично требала да се догоди. Не постоје тврдње око величине кода која је евентуално уграђена са извозом производа, нити око њене ефикасности и концизности. Коришћење било ког библиотекарског решења неопходно повлачи са собом додатке и некоришћена спољна средства осим ако је програм везник компајлера и објекта правећи тесни (мали, потпуно контролисани, и одређени) извршни модул.

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

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

Примери[уреди]

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

Архитектура[уреди]

Према Прију,[8] програмски оквири се састоје из залеђених делова иврућих делова. Залеђени делови дефинишу свеобухватну архитектуру програмског система, мислећи се на основне компоненте и везе између њих. Оне остају непромењене (замрзнуте) и било ком делу оквира апликације. Врући делови представљају оне делове где програмери који користе оквир да додају свој код да додају функционалност специфичну за свој пројекат.

У окружењу објектно-орјентисаног програмирања, оквир се састоји из апстрактних и конкретних класа. Примери таквих оквира се састоје из компоновања и наслеђивања већ постојећих класа.[9]

Приликом развоја конкретног програмског система са програмским оквиром, програмери искоришћавају вруће делове у складу са специфичним потребама и неопходности система. Програмски оквири се ослањају на Холивудски принцип: "Не зовите нас, ми ћемо вас звати."[10] Ово значи да кориснички дефинисане класе (на пример, нове подкласе), добијају поруке из већ дефинисаних оквира класа. Програмери обично рукују са овим имплементирајући апстрактних метода наслеђивања.

Види још[уреди]

Референце[уреди]

  1. Riehle, Dirk (2000), Framework Design: A Role Modeling Approach (PDF), Swiss Federal Institute of Technology 
  2. „Framework”. DocForge. Приступљено 15. 12. 2008. 
  3. Vlissides, J M; Linton, M A (1990), „Unidraw: a framework for building domain-specific graphical editors”, ACM Transactions of Information Systems, 8 (3): 237—268, doi:10.1145/98188.98197 
  4. Johnson, R E (1992), „Documenting frameworks using patterns”, Proceedings of the Conference on Object Oriented Programming Systems Languages and Applications, ACM Press: 63—76 
  5. Birrer, A; Eggenschwiler, T (1993), „Proceedings of the European conference on object-oriented programming”, Frameworks in the financial engineering domain: an experience report, Springer-Verlag, стр. 21—35 
  6. Hill, C; DeLuca, C; Balaji, V; Suarez, M; da Silva, A (2004), „Architecture of the Earth System Modeling Framework (ESMF)”, Computing in Science and Engineering: 18—28 
  7. Gachet, A (2003), „Software Frameworks for Developing Decision Support Systems – A New Component in the Classification of DSS Development Tools”, Journal of Decision Systems, 12 (3): 271—281 
  8. Pree, W (1994), „Meta Patterns: A Means for Capturing the Essentials of Reusable Object-Oriented Design”, Proceedings of the 8th European Conference on Object-Oriented Programming, Springer-Verlag: 150—162 
  9. Buschmann, F (1996), Pattern-Oriented Software Architecture Volume 1: A System of Patterns. Chichester, Wiley, ISBN 978-0-471-95869-7 
  10. Larman, C (2001), Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (2nd изд.), Prentice Hall, ISBN 978-0-13-092569-5 

Спољашње везе[уреди]