Интерфейс пользователя с программой пакетом прикладных программ или вычислительной системой

Общий термин API (application program interface, интерфейс прикладного программирования) разделяется на следующие направления:

– API как интерфейс высокого уровня, принадлежащий к библиотекам RTL;

– API прикладных и системных программ, входящих в поставку операционной системы;

Интерфейс прикладного программирования, как это и следует из названия, предназначен для использования прикладными программами системных ресурсов ОС и реализуемых ею функций. API описывает совокупность функций и процедур, принадлежащих ядру или надстройкам ОС.

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

Целевая вычислительная система представляет собой совокупность программных и аппаратных средств, в окружении которых выполняется результирующая программа. Сама результирующая программа порождается системой программирования на основании кода исходной программы, соз­данного разработчиком, а также объектных модулей и библиотек, входящих в состав системы программирования.

HTTP. От гипертекста до интерфейса пользователя и зачем Google свой браузер.

Функции API позволяют разработчику строить результирующую прикладную программу так, чтобы использовать средства целевой вычислительной системы для выполнения типовых операций. При этом разработчик программы избавлен от необходимости создавать исходный код для выполнения этих операций.

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

Существует несколько вариантов реализации API:

– реализация на уровне ОС;

– реализация на уровне системы программирования;

– реализация на уровне внешней библиотеки процедур и функций.

Система программирования в каждом из этих вариантов предоставляет разработчику средства для подключения функций API к исходному коду программы и организации их вызовов. Объектный код функций API подключается к резуль­тирующей программе компоновщиком при необходимости.

Возможности API можно оценивать со следующих позиций:

– эффективность выполнения функций API – включает в себя скорость выполнения функций и объем вычислительных ресурсов, потребных для их выполнения;

– широта предоставляемых возможностей;

– зависимость прикладной программы от архитектуры целевой вычислительной системы.

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

Реализация функций API на уровне ОС

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

Пользовательский интерфейс и его разновидности | Информатика 7 класс #16 | Инфоурок

В таком варианте результирующая программа обращается непосредственно к ОС. Поэтому достигается наибольшая эффективность выполнения функций API по сравнению со всеми другими вариантами реализации API.

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

Таким образом, в данной схеме для переноса прикладной программы с одной целевой вычислительной системы на другую будет требоваться изменение исходного кода программы.

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

Хорошо известным примером API такого рода может служить набор функций, предоставляемых пользователю со стороны ОС типа Microsoft Windows – WinAPI (Windows API). Надо сказать, что даже внутри этого корпоративного API существует определенная несогласованность, которая несколько ограничивает пере­носимость программ между различными ОС типа Windows.

Еще одним примером такого API можно считать набор сервисных функций ОС типа MS-DOS, реализованный в виде набора подпрограмм обслуживания программных преры­ваний.

Реализация функций API на уровне системы программирования

Если функции API реализуются на уровне системы программирования, они предоставляются пользователю в виде библиотеки функций соответствующего языка программирования. Обычно речь идет о библиотеке времени исполнения – RTL (run time library).

Система программирования предоставляет пользователю библиотеку соответствующего языка программирования и обеспечивает подклю­чение к результирующей программе объектного кода, ответственного за выполнение этих функций.

Очевидно, что эффективность функций API в таком варианте будет несколько ниже, чем при непосредственном обращении к функциям ОС. Так происходит, поскольку для выполнения многих функций API библиотека RTL языка про­граммирования должна все равно выполнять обращения к функциям ОС. Наличие всех необходимых вызовов и обращений к функциям ОС в объектном коде RTL обеспечивает система программирования.

Однако переносимость исходного кода программы в таком варианте будет самой высокой, поскольку синтаксис и семантика всех функций будут строго регламентированы в стандарте соответствующего языка программирования. Они за­висят от языка и не зависят от архитектуры целевой вычислительной системы. Поэтому для выполнения прикладной программы на новой архитектуре вычислительной системы достаточно заново построить код результирующей программы с помощью соответствующей системы программирования.

Единообразное выполнение функций языка обеспечивается системой программирования. При ориентации на различные архитектуры целевой вычислительной системы в системе программирования могут потребоваться различные комбина­ции вызовов функций ОС для выполнения одних и тех же функций исходного языка. Это должно быть учтено в коде RTL. В общем случае для каждой архитектуры целевой вычислительной системы будет требоваться свой код RTL языка программирования. Выбор того или иного объектного кода RTL для подключения к результирующей программе система программирования обеспечивает автоматически.

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

Как правило, набора стандартных функций оказывается недостаточно для создания полноценной прикладной программы. Тогда разработчик может обратиться к функциям других библиотек, имеющихся в составе системы программирования. В этом случае нет гарантии, что функции, включенные в состав данной системы программирования, но не входящие в стандарт языка программирования, будут доступны в другой системе программирования. Особенно если она ориентирована на другую архитектуру целевой вычислительной системы. Такая ситуация уже ближе к третьему вари­анту реализации API.

Реализация функций API с помощью внешних библиотек

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

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

С точки зрения эффективности выполнения этот метод реализации API имеет самые низкие результаты, поскольку внешняя библиотека обращается как к функциям ОС, так и к функциям RTL языка программирования. Только при очень высоком качестве внешней библиотеки ее эффективность становится сравнимой с библиотекой RTL.

Если говорить о переносимости исходного кода, то здесь требование только одно – используемая внешняя библиотека должна быть доступна в любой из архитектур вычислительных систем, на которые ориентирована прикладная программа. Тогда удается достигнуть переносимости. Это возможно, если используемая биб­лиотека удовлетворяет какому-то принятому стандарту, а система программирования поддерживает этот стандарт.

Например, библиотеки, удовлетворяющие стандарту POSIX, доступны в большинстве систем программирования для языка С. И если прикладная программа использует только библиотеки этого стандарта, то ее исходный код будет переносимым.

Для большинства специфических библиотек отдельных разработчиков это не так. Если пользователь использует какую-то библиотеку, то она ориентирована на ограниченный набор доступных архитектур целевой вычислительной системы. Примерами могут служить библиотеки MFC (Microsoft foundation classes) фирмы Microsoft и VCL (Visual Components Library) фирмы Borland, жестко ориентированные на архитектуру ОС типа Windows.

Тем не менее, многие фирмы-разработчики сейчас стремятся создать библиотеки, которые бы обеспечивали переносимость исходного кода приложений между различными архитектурами целевой вычислительной системы. К ним можно отнести библиотеку CLX (Component Library for Cross Platform) производства фирмы Borland ориентированную на архитектуру ОС типа Linux и ОС типа Windows.

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

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

Что касается прикладных программ, то гораздо большую перспективу для них предоставляют технологии, связанные с разработками в рамках архитектуры «клиент – сервер» или трехуровневой архитектуры создания приложений. В этом направлении ведущие производители ОС, СУБД и систем программирования скорее достигнут соглашений, чем в направлении стандартизации API.

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

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

Таким примером может служить очень известный и, пожалуй, один из самых распространенных стандартов – стандарт POSIX. В этом стандарте перечислен большой набор функций, их параметров и возвращаемых значений.

Стандартизированными, согласно POSIX, являются не только обращения к API, но и файловая система, организация доступа к внешним устройствам, набор системных команд. Использование в приложениях этого стандарта позволяет в дальнейшем легко переносить такие программы с одной ОС в другую путем про­стейшей перекомпиляции исходного текста.

Частным случаем попытки стандартизации API является внутренний корпоративный стандарт компании Microsoft, известный как WinAPI. Он включает в себя следующие реализации: Win 16, Win32s, Win32, WinCE.

С точки зрения WinAPI (в силу ряда идеологических причин – обязательный графический «оконный» интерфейс пользователя), базовой задачей является окно. Таким образом, WinAPI изначально ориентирован на работу в графической среде. Однако базовые понятия дополнены традиционными функциями, в том числе частично поддержива­ется стандарт POSIX.

Источник: studfile.net

Операционная система и ППП

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

Наиболее распространенные операционные системы: MS-DOS, OS/2, UNIX, WINDOWS, LINUX,WINDOWS NT, они имеют разные модификации.

Операционная система (ОС) — это совокупность программных средств, осуществляющих управление ресурсами ЭВМ, запуск прикладных программ и их взаимодействие с внешними устройствами и другими программами, а также обеспечивающих диалог пользователя с компьютером.

Ресурсом является любой компонент ЭВМ и предоставляемые им возможности: центральный процессор, оперативная или внешняя память, внешнее устройство, программа и т. д.

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

Программный интерфейс — это совокупность средств, обеспечивающих взаимодействие устройств и программ в рамках вычислительной системы.

Пользовательский интерфейс — это программные и аппаратные средства взаимодействия пользователя с программой или ЭВМ. В свою очередь, пользовательский интерфейс может быть командным или объектно-ориентированным. Командный интерфейс предполагает ввод пользователем команд с клавиатуры при выполнении действий по управлению ресурсами компьютера.

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

Каждый компьютер обязательно комплектуется операционной системой, для каждой из которых создается свой набор прикладных программ (приложений). Большинство операционных систем модифицируются и совершенствуются в направлении исправления ошибок и включения новых возможностей. В целях сохранения преемственности новая модификация операционной системы не переименовывается, а приобретает название версии. Версии ОС обозначаются (как правило) «десятичной дробью» вида 6.00, 2.1, 3.5 и т. д. При этом увеличение цифры до точки отражает существенные изменения, вносимые в операционную систему, а увеличение цифр, стоящих после точки, — незначительные изменения (например, исправление ошибок). Чем больше номер версии, тем большими возможностями обладает система.

Классификация операционных систем

Операционные системы классифицируются по:

· количеству одновременно работающих пользователей: однопользовательские, многопользовательские;

· числу процессов, одновременно выполняемых под управлением системы: однозадачные, многозадачные;

· количеству поддерживаемых процессоров: однопроцессорные, многопроцессорные;

· разрядности кода ОС: 8-разрядные, 16-разрядные, 32-разрядные, 64-разрядные;

· типу интерфейса: командные (текстовые) и объектно-ориентированные (графические);

· типу доступа пользователя к ЭВМ: с пакетной обработкой, с разделением времени, реального времени;

· типу использования ресурсов: сетевые, локальные.

В соответствии с первым признаком классификации многопользовательские операционные системы, в отличие от однопользовательских, поддерживают одновременную работу на ЭВМ нескольких пользователей за различными терминалами.

Второй признак предполагает деление ОС на многозадачные и однозадачные. Понятие многозадачности означает поддержку параллельного выполнения нескольких программ, существующих в рамках одной вычислительной системы, в один момент времени. Однозадачные ОС поддерживают режим выполнения только одной программы в отдельный момент времени.

В соответствии с третьим признаком многопроцессорные ОС, в отличие от однопроцессорных, поддерживают режим распределения ресурсов нескольких процессоров для решения той или иной задачи.

Четвертый признак подразделяет операционные системы на 8-, 16-, 32- и 64-разрядные. При этом подразумевается, что разрядность операционной системы не может превышать разрядности процессора.

В соответствии с пятым признаком ОС по типу пользовательского интерфейса делятся на объектно-ориентированные (как правило, с графическим интерфейсом) и командные (с текстовым интерфейсом). Согласно шестому признаку ОС подразделяются на системы:

· пакетной обработки, в которых из программ, подлежащих выполнению, формируется пакет (набор) заданий, вводимых в ЭВМ и выполняемых в порядке очередности с возможным учетом приоритетности;

· разделения времени (TSR), обеспечивающих одновременный диалоговый (интерактивный) режим доступа к ЭВМ нескольких пользователей на разных терминалах, которым по очереди выделяются ресурсы машины, что координируется операционной системой в соответствии с заданной дисциплиной обслуживания;

· реального времени, обеспечивающих определенное гарантированное время ответа машины на запрос пользователя с управлением им какими-либо внешними но отношению к ЭВМ событиями, процессами или объектами.

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

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

В настоящее время распространены следующие семейства операционных систем: DOS; OS/2; UNIX; Windows; ОС реального времени.

Основные критерии подхода к выбору операционной системы:

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

Чтобы выбрать ту или иную ОС, необходимо знать:

· на каких аппаратных платформах и с какой скоростью работает ОС;

· какое периферийное аппаратное обеспечение ОС поддерживает;

· как полно удовлетворяет ОС потребности пользователя, то есть каковы функции системы;

· каков способ взаимодействия ОС с пользователем, то есть насколько нагляден, удобен, понятен и привычен пользователю интерфейс;

· существуют ли информативные подсказки, встроенные справочники и т. д.;

· какова надежность системы, то есть ее устойчивость к ошибкам пользователя, отказам оборудования и т. д.;

· какие возможности предоставляет ОС для организации сетей;

· обеспечивает ли ОС совместимость с другими операционными системами;

· какие инструментальные средства имеет ОС для разработки прикладных программ;

· осуществляется ли в ОС поддержка различных национальных языков;

· какие известные пакеты прикладных программ можно использовать при работе с данной системой;

как осуществляется в ОС защита информации и самой системы.

Аальтернативная стоимость. Кривая производственных возможностей В экономике Буридании есть 100 ед. труда с производительностью 4 м ткани или 2 кг мяса.

Вычисление основной дактилоскопической формулы Вычислением основной дактоформулы обычно занимается следователь. Для этого все десять пальцев разбиваются на пять пар.

Расчетные и графические задания Равновесный объем — это объем, определяемый равенством спроса и предложения.

Кардиналистский и ординалистский подходы Кардиналистский (количественный подход) к анализу полезности основан на представлении о возможности измерения различных благ в условных единицах полезности.

Объект, субъект, предмет, цели и задачи управления персоналом Социальная система организации делится на две основные подсистемы: управляющую и управляемую.

Законы Генри, Дальтона, Сеченова. Применение этих законов при лечении кессонной болезни, лечении в барокамере и исследовании электролитного состава крови Закон Генри: Количество газа, растворенного при данной температуре в определенном объеме жидкости, при равновесии прямо пропорциональны давлению газа.

Ганглиоблокаторы. Классификация. Механизм действия. Фармакодинамика. Применение.Побочные эфффекты Никотинчувствительные холинорецепторы (н-холинорецепторы) в основном локализованы на постсинаптических мембранах в синапсах скелетной мускулатуры.

Оценка качества Анализ документации. Имеющийся рецепт, паспорт письменного контроля и номер лекарственной формы соответствуют друг другу. Ингредиенты совместимы, расчеты сделаны верно, паспорт письменного контроля выписан верно. Правильность упаковки и оформления.

БИОХИМИЯ ТКАНЕЙ ЗУБА В составе зуба выделяют минерализованные и неминерализованные ткани.

Типология суицида. Феномен суицида (самоубийство или попытка самоубийства) чаще всего связывается с представлением о психологическом кризисе личности.

Источник: studopedia.info

Интерфейс прикладного программирования

API (англ. Application Programming Interface, интерфейс прикладного программирования) — набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) или операционной системой для использования во внешних программных продуктах.

Практически все операционные системы (UNIX, Windows, OS X и т.д.) имеют API, с помощью которого программисты могут создавать приложения для этой операционной системы. Главный API операционных систем — это множество системных вызовов.

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

В POSIXсуществует более 100 системных вызовов. Ниже приведены примеры наиболее часто применяемых системных вызовов стандарта POSIX:

• • fork — создание нового процесса;
• • exit — завершение процесса;
• • open — открывает файл;
• • close — закрывает файл;
• • read — читает данные из файла в буфер;
• • write — пишет данные из буфера в файл;
• • stat — получает информацию о состоянии файла;
• • mkdir — создает новый каталог;
• • rmdir — удаляет каталог;
• • link — создает ссылку;
• • unlink — удаляет ссылку;
• • mount — монтирует файловую систему;
• • umount — демонтирует файловую систему;
• • chdir — изменяет рабочий каталог.

B UNIX вызовы почти один к одному идентичны библиотечным процедурам, которые используются для обращения к системным вызовам.

Рассмотрим интерфейс прикладного программирования для Windows — Win32 API. Win32 API отделен от системных вызовов. Это позволяет в разных версиях менять системные вызовы, не переписывая программы. Поэтому непонятно, является ли вызов системным (выполняется ядром) или он обрабатывается в пространстве пользователя.

В Win32 API существует более 1000 вызовов. Такое количество связано и с тем, что графический интерфейс пользователя UNIX запускается в пользовательском режиме, а в Windows — встроен в ядро. Поэтому Win32 API имеет много вызовов для управления окнами, текстом, шрифтами т.д.

Вызовы Win32 API подобны вызовам стандарта POSIX. Примеры вызовов Win32API:

• • CreatProcess (fork) — создание нового процесса;
• • ExitProcess (exit) — завершение процесса;
• • CreatFile (open) — открывает файл;
• • Close Handle (close) — закрывает файл;
• • ReadFile (read) — читает данные из файла в буфер;
• • WriteFile (write) — пишет данные из буфера в файл;
• • CreatDirectory (mkdir) — создает новый каталог;
• • Remove Directory (rmdir) — удаляет каталог;
• • SetCurrentDirectoiy (chdir) — изменяет рабочий каталог. Интерфейс Win32 API позволяет программам работать почти

на всех версиях Windows.

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

С другой стороны, отличия в API различных операционных систем существенно затрудняют перенос приложений между платформами. Существуют различные методы обхода этой сложности — написание «промежуточных» API (API графических интерфейсов WxWidgets, Qt, GTK и т.п.), написание библиотек, которые отображают системные вызовы одной ОС в системные вызовы другой ОС (такие среды исполнения, как Wine, cygwin и т.п.), введение стандартов кодирования в языках программирования (например, стандартная библиотека языка С), написание интерпретируемых языков, реализуемых на разных платформах (sh, python, perl, php, tel, Java и т.д.).

Также необходимо отметить, что в распоряжении программиста часто находится несколько различных API, позволяющих добиться одного и того же результата. При этом каждый Л/Y обычно реализован с использованием API программных компонент более низкого уровня абстракции.

Например, для того чтобы увидеть в браузере строчку «Hello, world!», достаточно лишь создать HTML-документ с минимальным заголовком и простейшим телом, содержащим данную строку. Когда браузер откроет этот документ, программа-браузер передаст имя файла (или уже открытый дескриптор файла) библиотеке, обрабатывающей HTML-документы; та, в свою очередь, при помощи API операционной системы прочитает этот файл и разберется в его устройстве, затем последовательно вызовет через API библиотеки стандартных графических примитивов операции типа «очистить окошко», «написать “Hello, world!” выбранным шрифтом». Во время выполнения этих операций библиотека графических примитивов обратится к библиотеке оконного интерфейса с соответствующими запросами, уже эта библиотека обратится к API операционной системы, чтобы записать данные в буфер видеокарты.

При этом практически на каждом из уровней реально существует несколько возможных альтернативных API. Например, мы могли бы писать исходный документ не на HTML, а на LaTeX, для отображения могли бы использовать любой браузер. Различные браузеры, вообще говоря, используют различные //УМГ-библиотеки; и кроме того, все это может быть собрано с использованием различных библиотек примитивов и на различных операционных системах.

Основными сложностями существующих многоуровневых систем API, таким образом, являются:

• • сложность портирования программного кода с одной системы API на другую (например, при смене ОС);
• • потеря функциональности при переходе с более низкого уровня на более высокий. Грубо говоря, каждый «слой» API создается для облегчения выполнения некоторого стандартного набора операций. Но при этом реально затрудняется либо становится принципиально невозможным выполнение некоторых других операций, которые предоставляет более низкий уровень API.

Источник: studref.com