Википедија

Фрејмворк

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

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

  • Инверзија контроле: У фрејмворку, за разлику од библиотека или нормалних апликација корисника, свеобухватно програмско управљање током није наређивано од стране саговорника, већ од стране фрејмворка.[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. Архивирано из оригинала 07. 10. 2018. г. Приступљено 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 

Спољашње везе

уреди
 
Фрејмворк на Викимедијиној остави.
Преузето из „https://sr.wiki.x.io/w/index.php?title=Фрејмворк&oldid=27038179”