В компьютерном программировании программная среда — это абстракция , в которой программное обеспечение , обеспечивающее общие функциональные возможности, может выборочно изменяться дополнительным написанным пользователем кодом, обеспечивая тем самым программное обеспечение, специфичное для приложения. Он обеспечивает стандартный способ создания и развертывания приложений и представляет собой универсальную программную среду многократного использования , которая обеспечивает определенные функции как часть более крупной программной платформы для облегчения разработки программных приложений , продуктов и решений.
Программные платформы могут включать в себя вспомогательные программы, компиляторы, библиотеки кода, наборы инструментов и интерфейсы прикладного программирования (API) , которые объединяют все различные компоненты для обеспечения разработки проекта или системы .
У фреймворков есть ключевые отличительные особенности, которые отличают их от обычных библиотек :
Разработчики программных инфраструктур стремятся облегчить разработку программного обеспечения, позволяя дизайнерам и программистам посвящать свое время удовлетворению требований к программному обеспечению, а не работе с более стандартными низкоуровневыми деталями создания рабочей системы, тем самым сокращая общее время разработки. [2] Например, команда, использующая веб-фреймворк для разработки банковского веб-сайта, может сосредоточиться на написании кода, специфичного для банковского дела, а не на механике обработки запросов и управления состоянием .
Фреймворки часто увеличивают размер программ — явление, называемое « раздуванием кода ». Из-за потребностей приложений, ориентированных на потребности клиентов, в одном продукте иногда оказываются как конкурирующие, так и дополняющие друг друга платформы. Кроме того, из-за сложности их API запланированное сокращение общего времени разработки может быть не достигнуто из-за необходимости тратить дополнительное время на обучение использованию платформы; эта критика явно справедлива, когда сотрудники разработчиков впервые сталкиваются со специальной или новой структурой. [ нужна ссылка ] Если такая структура не используется в последующих рабочих задачах, время, затраченное на изучение структуры, может стоить больше, чем специально написанный код, знакомый персоналу проекта; многие программисты хранят копии полезного шаблонного кода для общих нужд.
Однако, как только структура будет изучена, будущие проекты можно будет выполнять быстрее и проще; Концепция фреймворка заключается в создании универсального набора решений, и по мере знакомства производство кода должно логически увеличиться. Никаких подобных заявлений не делается ни относительно размера кода, который в конечном итоге будет включен в выходной продукт, ни относительно его относительной эффективности и краткости. Использование любого библиотечного решения обязательно требует дополнительных и неиспользуемых посторонних ресурсов, если только программное обеспечение не является компоновщиком объектов-компиляторов, создающим компактный (небольшой, полностью контролируемый и заданный) исполняемый модуль.
Проблема остается, но более чем десятилетний опыт работы в отрасли [ нужна ссылка ] показал, что наиболее эффективными фреймворками оказываются те, которые развиваются в результате рефакторинга общего кода предприятия вместо использования общего «единого размера». "подходит всем", разработанная третьими лицами для общих целей. Примером этого может служить то, как пользовательский интерфейс в таком пакете приложений, как офисный пакет, приобретает общий внешний вид, атрибуты и методы совместного использования данных, поскольку некогда разрозненные объединенные приложения становятся унифицированными в более тесный пакет. и меньше; более новый/развитый пакет может представлять собой продукт, который использует общие библиотеки утилит и пользовательские интерфейсы.
Эта тенденция в полемике поднимает важный вопрос о фреймворках. Создание элегантной структуры, а не структуры, которая просто решает проблему, по-прежнему является скорее ремеслом, чем наукой. « Элегантность программного обеспечения » подразумевает ясность, краткость и минимум отходов (дополнительные или посторонние функции, большая часть которых определяется пользователем). Например, для тех фреймворков, которые генерируют код, «элегантность» будет означать создание кода, который является чистым и понятным для достаточно хорошо осведомленного программиста (и который, следовательно, легко модифицируется), а не кода, который просто генерирует правильный код. Проблема элегантности заключается в том, почему относительно немногие программные платформы выдержали испытание временем: лучшие платформы смогли изящно развиваться по мере развития базовой технологии, на которой они были построены. Даже там, после развития, многие такие пакеты сохранят устаревшие возможности, раздувая окончательную версию программного обеспечения, поскольку замененные в противном случае методы сохраняются параллельно с более новыми методами.
Программные платформы обычно содержат значительный объем служебного и служебного кода, помогающего загружать пользовательские приложения, но обычно сосредотачиваются на конкретных проблемных областях, таких как:
По мнению При, [8] программные среды состоят из «замороженных» и «горячих» точек . Замороженные точки определяют общую архитектуру программной системы, то есть ее основные компоненты и отношения между ними. Они остаются неизменными (замороженными) в любой реализации среды приложения. Горячие точки представляют собой те части, где программисты, использующие инфраструктуру, добавляют свой собственный код для добавления функциональности, специфичной для их собственного проекта.
В объектно-ориентированной среде структура состоит из абстрактных и конкретных классов . Создание экземпляра такой структуры состоит из создания и создания подклассов существующих классов. [9]
Необходимая функциональность может быть реализована с помощью шаблона метода шаблона , в котором замороженные точки известны как инвариантные методы, а горячие точки известны как варианты или методы-перехватчики. Инвариантные методы суперкласса обеспечивают поведение по умолчанию, а методы-перехватчики в каждом подклассе обеспечивают собственное поведение.
При разработке конкретной программной системы с программной средой разработчики используют «горячие точки» в соответствии с конкретными потребностями и требованиями системы. В основе программных платформ лежит голливудский принцип : «Не звоните нам, мы позвоним вам». [10] [11] Это означает, что определяемые пользователем классы (например, новые подклассы) получают сообщения от предопределенных классов платформы. Разработчики обычно справляются с этим, реализуя абстрактные методы суперкласса .
{{citation}}
: CS1 maint: дата и год ( ссылка )