Обратные вызовы в C++

Архитектурный дизайн вызовов

1.4.1. Синхронные и асинхронные вызовы

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

Синхронный вызов – архитектурный дизайн, в котором при вызове функции инициатора обратный вызов происходит до выхода из тела этой функции.

Асинхронный вызов – архитектурный дизайн, в котором обратный вызов может быть выполнен в любое время.

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

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

Рис. 9. Синхронные и асинхронные вызовы: а) синхронный; б) асинхронный

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

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

1.4.2. Использование вызовов в API

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

Интерфейс API – набор объявлений для вызова кода API.

При проектировании API должны соблюдаться следующие требования.

1. Интерфейс должен следовать определённым соглашениям. Следуя указанным соглашениям, стороннее приложение может осуществлять вызовы кода API.

2. Интерфейс должен быть изолирован от реализации. Должна существовать возможность изменения кода реализации без изменения интерфейса.

3. Код должен быть подготовлен к выполнению.