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

"Фреймворк (информатика)" перенаправляется сюда. Для использования в других целях см. Framework (значения).

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

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

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

Обоснование

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

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

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

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

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

Примеры

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

Архитектура

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

В объектно-ориентированный среды, каркас состоит из Абстрактные и конкретный классы. Создание такого каркаса состоит из составление и подклассы существующие классы.[9]

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

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

Смотрите также

Рекомендации

  1. ^ Риле, Дирк (2000), Дизайн каркаса: подход к ролевому моделированию (PDF), Швейцарский федеральный технологический институт
  2. ^ "Рамки". DocForge. Получено 15 декабря 2008.[мертвая ссылка ]
  3. ^ Vlissides, JM; Линтон, Массачусетс (1990), «Unidraw: структура для создания графических редакторов для конкретной предметной области», ACM-транзакции в информационных системах, 8 (3): 237–268, Дои:10.1145/98188.98197, S2CID  11248368
  4. ^ Джонсон, Р. Э. (1992), «Документирование фреймворков с использованием шаблонов», Материалы конференции по языкам и приложениям систем объектно-ориентированного программирования, ACM Press: 63–76
  5. ^ Биррер, А; Eggenschwiler, T (1993), "Труды европейской конференции по объектно-ориентированному программированию", Структуры в области финансового инжиниринга: отчет об опыте, Springer-Verlag, стр. 21–35
  6. ^ Хилл, С; ДеЛука, К; Баладжи, V; Суарес, М; да Силва, А (2004), «Архитектура модели моделирования системы Земля (ESMF)», Вычислительная техника в науке и технике, 6: 18–28, Дои:10.1109 / MCISE.2004.1255817, S2CID  9311752
  7. ^ Гаше, А. (2003 г.), «Программные платформы для разработки систем поддержки принятия решений - новый компонент в классификации инструментов разработки DSS», Журнал систем принятия решений, 12 (3): 271–281, Дои:10.3166 / jds.12.271-280, S2CID  29690836
  8. ^ При, В. (1994), "Мета-шаблоны: средство для захвата основ многоразового объектно-ориентированного дизайна", Материалы 8-й Европейской конференции по объектно-ориентированному программированию, Конспект лекций по информатике, Springer-Verlag, 821: 150–162, CiteSeerX  10.1.1.74.7935, Дои:10.1007 / BFb0052181, ISBN  978-3-540-58202-1
  9. ^ Бушманн, Ф (1996), Шаблонно-ориентированная архитектура программного обеспечения Том 1: Система шаблонов. Чичестер, Wiley, ISBN  978-0-471-95869-7
  10. ^ Ларман, К. (2001), Применение UML и шаблонов: введение в объектно-ориентированный анализ и дизайн, а также в унифицированный процесс (2-е изд.), Prentice Hall, ISBN  978-0-13-092569-5
  11. ^ Гамма, Эрих; Хелм, Ричард; Джонсон, Ральф; Влиссидес, Джон (1994). Шаблоны проектирования. Эддисон-Уэсли. ISBN  0-201-63361-2.

внешняя ссылка