Программный фреймворк

В компьютерном программировании , А программная среда представляет собой абстракции , в которой программное обеспечение обеспечивает общие функции могут быть выборочно изменен дополнительной написанной пользователем кода, обеспечивая таким образом приложения специального программного обеспечения. Он обеспечивает стандартный способ создания и развертывания приложений и представляет собой универсальную программную среду многократного использования, которая обеспечивает определенные функции как часть более крупной программной платформы для облегчения разработки программных приложений , продуктов и решений. Программные фреймворки могут включать вспомогательные программы, компиляторы, библиотеки кода, наборы инструментов и интерфейсы прикладного программирования (API).которые объединяют все различные компоненты для разработки проекта или системы .

У фреймворков есть ключевые отличительные особенности, которые отличают их от обычных библиотек :

инверсия управления : в каркасе, в отличие от библиотек или стандартных пользовательских приложений, общий поток управления программой диктуется не вызывающей стороной, а структурой. ^[1] Обычно это достигается с помощью шаблона метода шаблона .
поведение по умолчанию : это может быть обеспечено с помощью инвариантных методов шаблона метода шаблона в абстрактном классе, который предоставляется фреймворком.
расширяемость : пользователь может расширять структуру - обычно путем выборочного переопределения - или программисты могут добавлять специализированный пользовательский код для обеспечения определенных функций. Обычно это достигается с помощью метода перехвата в подклассе, который переопределяет метод шаблона в суперклассе.
немодифицируемый код фреймворка : код фреймворка, как правило, не предполагается изменять, принимая расширения, реализованные пользователем. Другими словами, пользователи могут расширять фреймворк, но не могут изменять его код.

Обоснование [ править ]

В этом разделе есть несколько проблем. Пожалуйста, помогите улучшить его или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалить эти сообщения-шаблоны )

Этот раздел требует дополнительных ссылок для проверки . Пожалуйста, помогите улучшить эту статью , добавив цитаты из надежных источников . Материал, не полученный от источника, может быть оспорен и удален.
Источники: «Программный фреймворк» - новости · газеты · книги · ученый · JSTOR ( апрель 2011 г. ) ( Узнайте, как и когда удалить это сообщение-шаблон )

Этот раздел может быть слишком длинным и излишне подробным. Пожалуйста, рассмотрите возможность обобщения материала со ссылкой на источники по мере необходимости. ( Апрель 2020 г. )

В этом разделе содержатся ласковые слова : расплывчатые формулировки, которые часто сопровождают предвзятую или непроверяемую информацию . Такие утверждения следует прояснить или удалить . ( Апрель 2020 г. )

Этот раздел написан как личное размышление, личное эссе или аргументированное эссе , в котором излагаются личные чувства редактора Википедии или представлены оригинальные аргументы по теме. Пожалуйста, помогите улучшить его , переписав в энциклопедическом стиле . ( Апрель 2020 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения )

( Узнайте, как и когда удалить этот шаблон сообщения )

Разработчики программных фреймворков стремятся облегчить разработку программного обеспечения, позволяя дизайнерам и программистам посвящать свое время удовлетворению требований к программному обеспечению, а не заниматься более стандартными низкоуровневыми деталями предоставления работающей системы, тем самым сокращая общее время разработки. ^[2] Например, команда, использующая веб-фреймворк для разработки банковского веб-сайта, может сосредоточиться на написании кода, специфичного для банковского дела, а не на механике обработки запросов и управления состоянием .

Фреймворки часто увеличивают размер программ - явление, называемое « раздуванием кода ». Из-за потребностей приложений, ориентированных на потребности клиентов, как конкурирующие, так и взаимодополняющие структуры иногда заканчиваются в продукте. Кроме того, из-за сложности их API запланированное сокращение общего времени разработки может не быть достигнуто из-за необходимости тратить дополнительное время на обучение использованию инфраструктуры; эта критика явно уместна, когда разработчики впервые сталкиваются с особой или новой структурой. ^{[ необходимая цитата ]} Если такая структура не используется в последующих рабочих задачах, время, потраченное на изучение структуры, может стоить больше, чем специально написанный код, знакомый сотрудникам проекта; многие программисты хранят копии полезных шаблонов для общих нужд.

Однако, как только структура будет изучена, будущие проекты можно будет выполнять быстрее и проще; концепция фреймворка состоит в том, чтобы создать универсальный набор решений, и со знанием дела производство кода должно логически расти. Нет таких заявлений ни о размере кода, который в конечном итоге связывается с выходным продуктом, ни о его относительной эффективности и лаконичности. Использование любого библиотечного решения обязательно влечет за собой дополнительные и неиспользуемые посторонние ресурсы, если только программное обеспечение не является компоновщиком объекта-компилятора, создающим жесткий (небольшой, полностью контролируемый и определенный) исполняемый модуль.

Проблема сохраняется, но более чем десятилетний опыт работы в отрасли ^{[ необходима цитата ]} показал, что наиболее эффективными являются те структуры, которые развиваются на основе повторного факторинга общего кода предприятия вместо использования универсального универсального кода. -подходит для всех », разработанная третьими сторонами для общих целей. Примером этого может быть то, как пользовательский интерфейс в таком пакете приложений, как офисный пакет, вырастает, чтобы иметь общий внешний вид, функции и атрибуты и методы совместного использования данных, поскольку когда-то разрозненные связанные приложения превращаются в единый пакет, который является более жестким. и меньше; более новый / усовершенствованный набор может быть продуктом, который разделяет встроенные служебные библиотеки и пользовательские интерфейсы.

Эта полемика поднимает важный вопрос о фреймворках. Создание элегантного фреймворка, а не просто решающего проблему, по-прежнему является скорее ремеслом, чем наукой. " Элегантность программного обеспечения"подразумевает ясность, лаконичность и небольшую потерю (лишняя или посторонняя функциональность, большая часть которой определяется пользователем). Например, для тех фреймворков, которые генерируют код," элегантность "будет означать создание чистого и понятного для разумного знающий программист (и поэтому его можно легко изменить) по сравнению с программистом, который просто генерирует правильный код. Проблема элегантности заключается в том, почему сравнительно немного программных фреймворков выдержали испытание временем: лучшие фреймворки смогли изящно развиваться как базовая технология, на которой они были созданы продвинутыми.Даже после развития многие такие пакеты сохранят унаследованные возможности, раздувая окончательное программное обеспечение, поскольку в противном случае замененные методы были сохранены параллельно с более новыми методами.

Примеры [ править ]

Программные фреймворки обычно содержат значительный объем служебного и служебного кода, чтобы помочь в загрузке пользовательских приложений, но, как правило, сосредоточены на определенных проблемных областях, таких как:

Художественный рисунок, музыкальная композиция и механические САПР ^[3]^[4]
Приложения финансового моделирования ^[5]
Приложения для моделирования земной системы ^[6]
Системы поддержки принятия решений ^[7]
Воспроизведение и создание мультимедиа
Веб-фреймворк
ПО промежуточного слоя
Cactus Framework - высокопроизводительные научные вычисления.
Платформа приложения - Общие приложения с графическим интерфейсом.
Фреймворк архитектуры предприятия
Фреймворк для разработки приложений Oracle
Laravel (PHP-фреймворк)

Архитектура [ править ]

Согласно При ^[8] программные фреймворки состоят из замороженных и горячих точек . Замороженные места определяют общую архитектуру программной системы, то есть ее основные компоненты и отношения между ними. Они остаются неизменными (замороженными) в любом экземпляре инфраструктуры приложения. Горячие точки представляют собой те части, где программисты, использующие фреймворк, добавляют свой собственный код для добавления функциональности, специфичной для их собственного проекта.

В объектно-ориентированной среде фреймворк состоит из абстрактных и конкретных классов . Создание такой структуры состоит из составления и создания подклассов существующих классов. ^[9]

Необходимая функциональность может быть реализована с помощью шаблона метода шаблона, в котором замороженные точки известны как инвариантные методы, а горячие точки известны как варианты или методы-перехватчики. Инвариантные методы в суперклассе обеспечивают поведение по умолчанию, в то время как методы ловушки в каждом подклассе обеспечивают настраиваемое поведение.

При разработке конкретной программной системы с программной структурой разработчики используют горячие точки в соответствии с конкретными потребностями и требованиями системы. Программные фреймворки основываются на голливудском принципе : «Не звоните нам, мы вам позвоним». ^[10]^[11] Это означает, что определенные пользователем классы (например, новые подклассы) получают сообщения от предопределенных классов инфраструктуры. Разработчики обычно справляются с этим, реализуя абстрактные методы суперкласса .

См. Также [ править ]

Найдите программный фреймворк в Викисловаре, бесплатном словаре.

Класс (информатика)
Шаблон проектирования (информатика)
Не повторяйся
Неявный вызов
Программный движок

Ссылки [ править ]

^ Riehle, Dirk (2000), Рамки Дизайн: Роль моделирования подход (PDF) , Швейцарский федеральный технологический институт
^ «Рамки» . DocForge . Проверено 15 декабря 2008 года . CS1 maint: обескураженный параметр ( ссылка )^{[ мертвая ссылка ]}
^ Vlissides, JM; Линтон, М. (1990), "Unidraw: основа для построения предметно-ориентированных графических редакторов", ACM Сделки по информационным системам , 8 (3): 237-268, DOI : 10,1145 / 98188,98197 , S2CID 11248368
^ Johnson, RE (1992), «Документирование фреймворков с использованием шаблонов», Труды конференции по языкам и приложениям объектно-ориентированных систем программирования , ACM Press: 63–76
^ Биррер, А; Эггеншвилер, Т. (1993), «Труды европейской конференции по объектно-ориентированному программированию», Структуры в области финансового инжиниринга: отчет об опыте , Springer-Verlag , стр. 21–35.
^ Хилл, C; ДеЛука, К; Баладжи, V; Суарес, М; да Силва, A (2004), "Архитектура системы Земли Modeling Framework (ESMF)" , Вычислительный в области науки и техники , 6 : 18-28, DOI : 10,1109 / MCISE.2004.1255817 , S2CID 9311752
^ Гаше, A (2003), "Программное обеспечение Каркасы Разработка систем поддержки принятия решений - новый компонент в классификации средств разработки ДСС", Журнал Decision Systems , 12 (3): 271-281, DOI : 10.3166 / jds.12.271 -280 , S2CID 29690836
^ При, В. (1994), «Мета-шаблоны: средство для захвата основ многоразового объектно-ориентированного дизайна», Труды 8-й Европейской конференции по объектно-ориентированному программированию , конспекты лекций по информатике, Springer-Verlag , 821 : 150-162, CiteSeerX 10.1.1.74.7935 , DOI : 10.1007 / BFb0052181 , ISBN 978-3-540-58202-1
^ Buschmann, F (1996), Узор-ориентированная программная архитектура Том 1: Система паттернов. Чичестер , Вили , ISBN 978-0-471-95869-7
^ Ларман, C (2001), Применение UML и шаблонов: Введение в объектно-ориентированный анализ и дизайн и унифицированный процесс (2-е изд.), Прентис Холл , ISBN 978-0-13-092569-5
^ Гамма, Эрих ; Хелм, Ричард ; Джонсон, Ральф ; Влиссидес, Джон (1994). Шаблоны проектирования . Эддисон-Уэсли. ISBN 0-201-63361-2. CS1 maint: discouraged parameter (link)

Внешние ссылки [ править ]

Викискладе есть медиафайлы, связанные с программными фреймворками .

[1] Riehle, Dirk (2000), Рамки Дизайн: Роль моделирования подход (PDF) , Швейцарский федеральный технологический институт

[2] «Рамки» . DocForge . Проверено 15 декабря 2008 года . CS1 maint: обескураженный параметр ( ссылка )^{[ мертвая ссылка ]}

[3] Vlissides, JM; Линтон, М. (1990), "Unidraw: основа для построения предметно-ориентированных графических редакторов", ACM Сделки по информационным системам , 8 (3): 237-268, DOI : 10,1145 / 98188,98197 , S2CID 11248368

[4] Johnson, RE (1992), «Документирование фреймворков с использованием шаблонов», Труды конференции по языкам и приложениям объектно-ориентированных систем программирования , ACM Press: 63–76

[5] Биррер, А; Эггеншвилер, Т. (1993), «Труды европейской конференции по объектно-ориентированному программированию», Структуры в области финансового инжиниринга: отчет об опыте , Springer-Verlag , стр. 21–35.

[6] Хилл, C; ДеЛука, К; Баладжи, V; Суарес, М; да Силва, A (2004), "Архитектура системы Земли Modeling Framework (ESMF)" , Вычислительный в области науки и техники , 6 : 18-28, DOI : 10,1109 / MCISE.2004.1255817 , S2CID 9311752

[7] Гаше, A (2003), "Программное обеспечение Каркасы Разработка систем поддержки принятия решений - новый компонент в классификации средств разработки ДСС", Журнал Decision Systems , 12 (3): 271-281, DOI : 10.3166 / jds.12.271 -280 , S2CID 29690836

[8] При, В. (1994), «Мета-шаблоны: средство для захвата основ многоразового объектно-ориентированного дизайна», Труды 8-й Европейской конференции по объектно-ориентированному программированию , конспекты лекций по информатике, Springer-Verlag , 821 : 150-162, CiteSeerX 10.1.1.74.7935 , DOI : 10.1007 / BFb0052181 , ISBN 978-3-540-58202-1

[9] Buschmann, F (1996), Узор-ориентированная программная архитектура Том 1: Система паттернов. Чичестер , Вили , ISBN 978-0-471-95869-7

[10] Ларман, C (2001), Применение UML и шаблонов: Введение в объектно-ориентированный анализ и дизайн и унифицированный процесс (2-е изд.), Прентис Холл , ISBN 978-0-13-092569-5

[11] Гамма, Эрих ; Хелм, Ричард ; Джонсон, Ральф ; Влиссидес, Джон (1994). Шаблоны проектирования . Эддисон-Уэсли. ISBN 0-201-63361-2. CS1 maint: discouraged parameter (link)

[1]