Введение
Тип библиотеки, помогающей структурировать другое программное обеспечение.
В компьютерном программировании программный каркас (фреймворк) – это абстракция, в которой программное обеспечение, предоставляющее общую функциональность, может быть выборочно изменено дополнительным кодом, написанным пользователем, тем самым обеспечивая программное обеспечение, специфичное для конкретного приложения. Он предоставляет стандартный способ создания и развертывания приложений и является универсальной, многократно используемой программной средой, которая предоставляет определенную функциональность в рамках более крупной программной платформы для упрощения разработки программных приложений, продуктов и решений. Программные каркасы могут включать в себя вспомогательные программы, компиляторы, библиотеки кода, наборы инструментов и интерфейсы прикладного программирования (API), которые объединяют все различные компоненты для разработки проекта или системы. Каркасы обладают ключевыми отличительными особенностями, которые отличают их от обычных библиотек:
инверсия управления: В каркасе, в отличие от библиотек или стандартных пользовательских приложений, общий поток управления программой диктуется не вызывающей стороной, а самим каркасом. Это обычно достигается с помощью шаблона "Метод-шаблон". поведение по умолчанию: Оно может быть обеспечено инвариантными методами шаблона "Метод-шаблон" в абстрактном классе, предоставляемом каркасом. расширяемость: Пользователь может расширить каркас – обычно путем выборочного переопределения – или программисты могут добавить специализированный код пользователя для предоставления конкретной функциональности. Это обычно достигается с помощью метода-крючка в подклассе, который переопределяет метод-шаблон в суперклассе. неизменяемость кода каркаса: Код каркаса, как правило, не должен изменяться, при этом принимаются расширения, реализованные пользователем. Иными словами, пользователи могут расширять каркас, но не могут изменять его код.
Обоснование
Конструкторы программных фреймворков стремятся упростить разработку программного обеспечения, позволяя разработчикам и программистам сосредоточиться на удовлетворении требований к ПО, а не на решении стандартных задач низкого уровня, связанных с созданием работоспособной системы, тем самым сокращая общее время разработки. Например, команда, использующая веб-фреймворк для разработки банковского сайта, может сосредоточиться на написании кода, специфичного для банковской деятельности, а не на механизмах обработки запросов и управления состоянием. Фреймворки часто увеличивают размер программ, что известно как "раздувание кода". В силу потребностей, определяемых запросами клиентов, в продукте могут оказаться как конкурирующие, так и взаимодополняющие фреймворки. Более того, из-за сложности их API ожидаемое сокращение общего времени разработки может не быть достигнуто из-за необходимости тратить дополнительное время на изучение фреймворка; эта критика особенно справедлива, когда разработчики впервые сталкиваются со специализированным или новым фреймворком. Если такой фреймворк не используется в последующих задачах, время, затраченное на его изучение, может оказаться дороже, чем разработка кода с нуля, знакомого команде проекта; многие программисты хранят копии полезных шаблонов кода для общих задач. Однако, после освоения фреймворка, будущие проекты можно будет завершить быстрее и проще; идея фреймворка заключается в создании универсального набора решений, и с приобретением опыта производительность кода должна логически возрастать. Никаких заявлений о размере кода, который в конечном итоге будет включен в конечный продукт, а также об его относительной эффективности и краткости, не делается. Использование любого библиотечного решения неизбежно приводит к включению дополнительных и неиспользуемых ресурсов, если только программное обеспечение не является компоновщиком, создающим компактный (небольшой, полностью контролируемый и определенный) исполняемый модуль. Эта проблема сохраняется, но более чем десятилетний опыт работы в отрасли показал, что наиболее эффективными оказываются фреймворки, которые развиваются в результате рефакторинга общего кода предприятия, а не использование универсального фреймворка "одного размера", разработанного сторонними разработчиками для общих целей. Примером может служить то, как пользовательский интерфейс в прикладном пакете, таком как офисный пакет, приобретает общий внешний вид, ощущение и атрибуты обмена данными, поскольку ранее разрозненные приложения объединяются в более тесный и компактный пакет; обновленный/эволюционировавший пакет может быть продуктом, который использует общие библиотеки утилит и пользовательские интерфейсы. Эта тенденция в дискуссии поднимает важный вопрос о фреймворках. Создание элегантного фреймворка, а не просто решения проблемы, по-прежнему больше похоже на ремесло, чем на науку. "Элегантность программного обеспечения" подразумевает ясность, лаконичность и минимальное количество избыточности (дополнительных или ненужных функций, большая часть которых определяется пользователем). Для фреймворков, генерирующих код, "элегантность" подразумевает создание кода, который является чистым и понятным для компетентного программиста (и, следовательно, легко поддается модификации), а не просто генерирует правильный код. Именно проблема элегантности объясняет, почему лишь немногие программные фреймворки выдержали испытание временем: лучшие фреймворки способны изящно развиваться по мере совершенствования базовых технологий, на которых они построены. Даже в этом случае, после эволюции, многие такие пакеты сохраняют устаревшие возможности, раздувая конечное программное обеспечение, поскольку устаревшие методы сохраняются параллельно с новыми.
Архитектура
По словам При, программные фреймворки состоят из фиксированных и изменяемых точек. Фиксированные точки определяют общую архитектуру программной системы, то есть её основные компоненты и связи между ними. Они остаются неизменными (фиксированными) при любом использовании фреймворка. Изменяемые точки – это части, в которых программисты, использующие фреймворк, добавляют свой код для реализации функциональности, специфичной для их проекта. В объектно-ориентированной среде фреймворк состоит из абстрактных и конкретных классов. Создание экземпляра такого фреймворка заключается в компоновке и наследовании существующих классов. Необходимую функциональность можно реализовать с помощью шаблона "Шаблонный метод", в котором фиксированные точки называются инвариантными методами, а изменяемые точки – вариантами или методами-крючками. Инвариантные методы в суперклассе предоставляют поведение по умолчанию, а методы-крючки в каждом подклассе – пользовательское поведение. При разработке конкретной программной системы с использованием фреймворка, разработчики используют изменяемые точки в соответствии со специфическими потребностями и требованиями системы. Программные фреймворки опираются на принцип Голливуда: "Не звоните нам, мы вам позвоним". Это означает, что пользовательские классы (например, новые подклассы) получают сообщения от предопределенных классов фреймворка. Разработчики обычно реализуют это, переопределяя абстрактные методы суперкласса.