пространство имён <SI-Namespace>::proxy::fields

Пространство имён <SI-Namespace>::proxy::fields инкапсулирует в модуле com платформы Adaptive Platform сгенерированные прокси-классы <Field> для каждого поля данных, определённого в ServiceInterface. Клиентские приложения обращаются к этим классам полей через вышестоящий прокси сервиса, чтобы запрашивать удалённые значения полей, задавать их или обрабатывать уведомления об изменении значений. При этом вызовы над полями, вероятно, выполняются асинхронно через коммуникационную инфраструктуру для обеспечения неблокирующего взаимодействия. Вопрос (открытый) Время жизни отдельных экземпляров полей, предположительно, жестко связано с жизненным циклом вышестоящего прокси-объекта и не может управляться независимо от него.

больше ›

Контекст

Пространство имён C++ <SI-Namespace>::proxy::fields выполняет в модуле com платформы AUTOSAR Adaptive Platform четко разграниченную функцию структурирования сервисно-ориентированных интерфейсов. Интерфейсы сервисов (ServiceInterfaces) наряду с методами и событиями часто определяют поля данных, представляющие текущее состояние. Чтобы предоставить эти поля на стороне клиента потребителям сервиса типобезопасным и семантически однозначным образом, генератор кода помещает специфические классы полей в это выделенное дочернее пространство имён. Для каждого поля, смоделированного в соответствующем ServiceInterface, создаётся ровно один прокси-класс поля <Field>. Такая структурная инкапсуляция предотвращает конфликты имён с одноимёнными методами или событиями в пределах вышестоящего пространства имён прокси. Интерпретация: сгенерированные классы полей <Field> обычно предоставляют специализированные интерфейсные функции для операций Get, Set и нотификаций, позволяя целенаправленно опрашивать, изменять значения или принимать изменения по подписке. Вопрос Q-f088d0c5052459d3 (открытый) Прямым партнёром по взаимодействию для классов полей выступает логика приложения потребителя сервиса с одной стороны и базовое коммуникационное промежуточное программное обеспечение — с другой.

Жизненный цикл

Создание экземпляров и управление объектами из <SI-Namespace>::proxy::fields неразрывно связаны с архитектурой прокси сервиса. Разработчики приложений, как правило, не создают экземпляры сгенерированного класса <Field> вручную как самостоятельные переменные в куче или на стеке. Вместо этого время жизни экземпляра <Field>, предположительно, полностью привязано к жизненному циклу вышестоящего прокси сервиса, который содержит эти поля в качестве своих членов. Вопрос Q-4da7e86f88f269b1 (открытый) После успешного конструирования экземпляра прокси вслед за обнаружением подходящей конечной точки сервиса объекты полей инициализируются и приводятся в состояние готовности к работе. В активной фазе объект поля управляет внутренними ресурсами связи, а также возможными регистрациями для получения обновлений состояния. Если приложение уничтожает экземпляр прокси или он выходит из области видимости, то закономерно деконструируются и соответствующие экземпляры полей, благодаря чему освобождаются связанные ресурсы промежуточного программного обеспечения.

Путь использования

Типичная последовательность использования классов в пространстве имён <SI-Namespace>::proxy::fields состоит из фиксированного ряда шагов взаимодействия. Сначала клиентское приложение определяет экземпляр требуемого сервиса с помощью механизмов поиска Adaptive Platform и создаёт экземпляр соответствующего прокси сервиса. На втором шаге приложение обращается через прокси к соответствующему экземпляру-члену сгенерированного класса <Field>. В зависимости от свойств поля, определённых в модели интерфейса, приложение затем инициирует операцию чтения, операцию записи либо регистрирует функцию обратного вызова для уведомлений об изменении значений. Вызовы полей при этом, вероятно, обрабатываются асинхронно через ara::core::Future или механизмы обратного вызова коммуникационной инфраструктуры, чтобы избежать блокирующих вызовов в вызывающем потоке. Вопрос Q-33586a48d8777f7f (открытый) После поступления ответа или уведомления вызывающая сторона анализирует полученный результат и реагирует на состояние удалённого поля.