Задача дизайна - прокинуть детали низкоуровневой реализации на более высокий уровень и вернуть обратно

@Kastaneda · Регистрация: 12.12.2009

Студворк — интернет-сервис помощи студентам

Привет!

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

Итак - есть RPC канал, который реагирует на события AMQP сервера (используется событийная модель). Из RPC канала нужно асинхронно ответить на сообщение, для этого AMQP нужны данные, о которых знает только AMQP. Т.е. эти данные нужно прокинуть из AMQP в RPC, и RPC потом должен эти данные вернуть. Чтоб все было кошерно нужно:
1. Чтобы RPC не знал об AMQP (транспорт должен быть заменяемым)
2. Не нужно заставлять пользователя (т.е. RPC) что-то куда-то прокидывать

Чтоб было понятней (очень упращенный вариант)

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// AMQP
void AmqpServer::mainLoop()
{
    // что-то делаем, в итоге получаем сообщение
   // при этом есть некий ID, который нужно знать при отправке ответа
   
    _messageHandler->onMessageReceived(message/*, также нужно как-то прокинуть упомянутый ID*/);
}
 
void AmqpServer::sendResponse (std::string response, /* и еще нужно знать упомянутый выше ID*/)
{
    // отправляем сообщение, используя ID
}
 
// RPC
void RpcChannel::onMessageReceived (std::string message/*, нужен еще ID*/)
{
    // обработали сообщение, сформировали ответ
 
    _responseHandler->sendResponse(response/*, плюс нужно вернуть ID*/);
}

Вариант с кешированием IDшников на стороне сервера сразу отметаем по ряду причин. Есть предложения?

@vxg · 22.11.2016, 13:57

Kastaneda, для тех кто не знает что такое AMQP и RPC можно сформулировать или технические особенности этих заклинаний здесь принципиальны? если да, то этого почему-то не видно по примеру

@Kastaneda · 22.11.2016, 14:03 **[ТС]**

Сообщение от vxg

Kastaneda, для тех кто не знает что такое AMQP и RPC можно сформулировать или технические особенности этих заклинаний здесь принципиальны? если да, то этого почему-то не видно по примеру

Технические особенности не принципиальны. Попробую объяснить - AMQP это протокол передачи данных (по сети), используется в качестве транспорта. RPC - это тоже протокол, но более высокого уровня, ему без разницы через какой транспорт к нему пришло сообщение, хоть через HTTP.

Если проводить аналогию, то можно представить, что вместо AMQP имеется ввиду TCP, а вместо RPC - HTTP. И теперь представим, что для отправки HTTP ответа уровень HTTP должен знать о каких-то деталях реализации TCP, понятно, что это не правильно. И у нас получается, что уровень RPC должен знать об AMQP.

@vxg · 22.11.2016, 14:10

Kastaneda
то есть имеем объект 1-го уровня через который проходят данные попадающее объекту 2-го уровня и объекту 2-го уровня нужно знать об этих данных нечто доступное лишь объекту 1-го уровня?

@Kastaneda · 22.11.2016, 14:14 **[ТС]**

vxg, да и задача в том, чтобы оградить объект 2-го уровня от этих знаний, т.к. чисто теоретически тип объекта 1-го уровня может быть другим и иметь другую реализацию.

@vxg · 22.11.2016, 14:19

Kastaneda, если объект 1-го уровня может вызвать обработчик объекта 2-го уровня во время приема данных (вместо вызова обработчика неким стандартным механизмом) и передать в этом обработчике нужные данные наверное это самое естественное решение кроме кэша

@Kastaneda · 22.11.2016, 14:24 **[ТС]**

Сообщение от vxg

если объект 1-го уровня может вызвать обработчик объекта 2-го уровня во время приема данных (вместо вызова обработчика неким стандартным механизмом) и передать в этом обработчике нужные данные наверное это самое естественное решение кроме кэша

Оно выглядит просто, но оно не правильное. Завтра мы меняем AMQP на тот же HTTP и нам данные AMQP не нужны - придется переписываться код. Или мы хотим использовать 2 вида транспорта одновременно - тогда вообще получится несовместимость.

@vxg · 22.11.2016, 15:13

Kastaneda, если вы владеете структурой данных прикрепляйте нужную информацию нижнего уровня в экстру

@Kastaneda · 22.11.2016, 16:37 **[ТС]**

vxg, нужно передать 2 поля (в примере в 1-ом посте показал одно просто для примера), но в идеале кол-во полей должно быть любым, поэтому поле extra будет непонятно какого типа (не void* же делать

).

Сообщение от vxg

если вы владеете структурой

можно варьировать как угодно, пока есть возможность менять интерфейсы/сигнатуры.

@vxg · 22.11.2016, 16:45

Kastaneda, ну так сделать это поле std::list<VARIANT>

Добавлено через 38 секунд
или лучше std::map<std::string, VARIANT> что бы уж с именами)

Добавлено через 2 минуты
хотя с именами не айс, нужны цифровые идентификаторы)

Добавлено через 25 секунд
что бы проверились в CT и можно было спать спокойно

@Kastaneda · 23.11.2016, 07:38 **[ТС]**

Сообщение от vxg

или лучше std::map<std::string, VARIANT> что бы уж с именами)

Была такая идея, но это решение попахивает)

@vxg · 23.11.2016, 09:02

Kastaneda, идеал - это когда вы знаете поля которые вам нужны - тогда экстра это просто структура с вашими полями. Если поля неизвестны и могут меняться то иного способа кроме абстрактного списка логически вроде нет

@Kastaneda · 23.11.2016, 09:27 **[ТС]**

Сообщение от vxg

идеал - это когда вы знаете поля которые вам нужны - тогда экстра это просто структура с вашими полями

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

@vxg · 23.11.2016, 09:33

Kastaneda,
1 верхний уровень хочет знать что то что не дает ему стандартная реализация. для этого мы делаем экстру. если экстра различная для разных реализаций нижнего уровня (что само по себе странно ибо как тогда работает верхний уровень если он не знает какие доп данные ему нужны), то можно на верхнем уровне различать экстры по типам. например экстра TCP или экстра UDP и соответственно по разному с ними работать.
2 если разработчик неадекват, то он может просто не использовать ваши данные. если есть желание защитить сами данные из-за того что они используются еще где-то в цепочке можно возвращать их не в структуре, а в объекте с доступом к полям через get функции.

@Kastaneda · 23.11.2016, 09:51 **[ТС]**

Сообщение от vxg

верхний уровень хочет знать что то что не дает ему стандартная реализация.

В том то и дело, что верхнему уровню это не надо. Теоретически можно на нижнем уровне все кешировать и на верх ничего не отдавать, но кешировать нельзя по ряду причин. Поэтому приходится отдавать это на верх.

@vxg · 23.11.2016, 12:43

Сообщение от Kastaneda

В том то и дело, что верхнему уровню это не надо

это даже проще. тогда нижний уровень что ему надо положит в экстру и что надо из нее возьмет

IGPIGP · 23.11.2016, 12:58

Сообщение от Kastaneda

Итак - есть RPC канал, который реагирует на события AMQP сервера (используется событийная модель). Из RPC канала нужно асинхронно ответить на сообщение, для этого AMQP нужны данные, о которых знает только AMQP. Т.е. эти данные нужно прокинуть из AMQP в RPC, и RPC потом должен эти данные вернуть.

Kastaneda, как я понимаю (из сказанного):
-RPC не знает и не изменяет указанные данные, а пропускает их транзитом
-AMQP использует указанные данные как id для идентификации в момент получения ответа собственного состояния на момент отправки сообщения на которое данный ответ получен.
Верно?

@Kastaneda · 23.11.2016, 13:15 **[ТС]**

IGPIGP, да, все верно. Грубо говоря AMQP при отправке ответа добавляет в ответ данные, по которым можно понять на какой именно запрос этот ответ. И это детали реализации AMQP.

vxg, получается "кишками наружу")

@vxg · 23.11.2016, 13:24

Сообщение от IGPIGP

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

ооо... *откидывается на спинку кресла и начинает думать*

IGPIGP · 23.11.2016, 13:37

Сообщение от vxg

откидывается на спинку кресла и начинает думать

Андрей Ефимыч?

Сообщение от Kastaneda

да, все верно

И как я понимаю, кешировать нельзя из-за того что не на все сообщения могут быть ответы.

Тогда совет vxg, это выход.
Я бы добавил, что стоит проанализировать имеющийся пакет в прямом сообщении. На предмет есть ли там место для "комментария" в виде id.
Важно ещё проанализировать количество различных состояний дифференцируемых на предмет обработки ответа, чтобы понять какой длины поле следует выбрать.

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Desktop (MinGW): Рисуем цветные прямоугольники с помощью рисовальщика SDL3 на Си и C++ 8Observer8 17.03.2026 Содержание блога Финальные проекты на Си и на C++: finish-rectangles-sdl3-c. zip finish-rectangles-sdl3-cpp. zip	Символические и жёсткие ссылки в Linux. algri14 15.03.2026 Существует два типа ссылок — символические и жёсткие. Ссылка в Linux — это запись в каталоге, которая может указывать либо на inode «файла-ИСТОЧНИКА», тогда это будет «жёсткая ссылка» (hard link),. . .	[Owen Logic] Поддержание уровня воды в резервуаре количеством включённых насосов: моделирование и выбор регулятора ФедосеевПавел 14.03.2026 Поддержание уровня воды в резервуаре количеством включённых насосов: моделирование и выбор регулятора ВВЕДЕНИЕ Выполняя задание на управление насосной группой заполнения резервуара,. . .	делаю науч статью по влиянию грибов на сукцессию anaschu 13.03.2026 прикрепляю статью
SDL3 для Desktop (MinGW): Создаём пустое окно с нуля для 2D-графики на SDL3, Си и C++ 8Observer8 10.03.2026 Содержание блога Финальные проекты на Си и на C++: hello-sdl3-c. zip hello-sdl3-cpp. zip Результат:	Установка CMake и MinGW 13.1 для сборки С и C++ приложений из консоли и из Qt Creator в EXE 8Observer8 10.03.2026 Содержание блога MinGW - это коллекция инструментов для сборки приложений в EXE. CMake - это система сборки приложений. Здесь описаны базовые шаги для старта программирования с помощью CMake и. . .	Как дизайн сайта влияет на конверсию: 7 решений, которые реально повышают заявки Neotwalker 08.03.2026 Многие до сих пор воспринимают дизайн сайта как “красивую оболочку”. На практике всё иначе: дизайн напрямую влияет на то, оставит человек заявку или уйдёт через несколько секунд. Даже если у вас. . .	Модульная разработка через nuget packages DevAlt 07.03.2026 Сложившийся в . Net-среде способ разработки чаще всего предполагает монорепозиторий в котором находятся все исходники. При создании нового решения, мы просто добавляем нужные проекты и имеем. . .

@vxg Модератор 3409 / 2180 / 354 Регистрация: 13.01.2012 Сообщений: 8,461
	22.11.2016, 13:57
	Kastaneda, для тех кто не знает что такое AMQP и RPC можно сформулировать или технические особенности этих заклинаний здесь принципиальны? если да, то этого почему-то не видно по примеру 1

@vxg Модератор 3409 / 2180 / 354 Регистрация: 13.01.2012 Сообщений: 8,461
	22.11.2016, 14:10
	Kastaneda то есть имеем объект 1-го уровня через который проходят данные попадающее объекту 2-го уровня и объекту 2-го уровня нужно знать об этих данных нечто доступное лишь объекту 1-го уровня? 0

@Kastaneda 5232 / 3205 / 362 Регистрация: 12.12.2009 Сообщений: 8,143 Записей в блоге: 2
	22.11.2016, 14:14 [ТС]
	vxg, да и задача в том, чтобы оградить объект 2-го уровня от этих знаний, т.к. чисто теоретически тип объекта 1-го уровня может быть другим и иметь другую реализацию. 0

@vxg Модератор 3409 / 2180 / 354 Регистрация: 13.01.2012 Сообщений: 8,461
	22.11.2016, 14:19
	Kastaneda, если объект 1-го уровня может вызвать обработчик объекта 2-го уровня во время приема данных (вместо вызова обработчика неким стандартным механизмом) и передать в этом обработчике нужные данные наверное это самое естественное решение кроме кэша 0

@vxg Модератор 3409 / 2180 / 354 Регистрация: 13.01.2012 Сообщений: 8,461
	22.11.2016, 15:13
	Kastaneda, если вы владеете структурой данных прикрепляйте нужную информацию нижнего уровня в экстру 0

@vxg Модератор 3409 / 2180 / 354 Регистрация: 13.01.2012 Сообщений: 8,461
	22.11.2016, 16:45
	Kastaneda, ну так сделать это поле std::list<VARIANT> Добавлено через 38 секунд или лучше std::map<std::string, VARIANT> что бы уж с именами) Добавлено через 2 минуты хотя с именами не айс, нужны цифровые идентификаторы) Добавлено через 25 секунд что бы проверились в CT и можно было спать спокойно 0

@vxg Модератор 3409 / 2180 / 354 Регистрация: 13.01.2012 Сообщений: 8,461
	23.11.2016, 09:02
	Kastaneda, идеал - это когда вы знаете поля которые вам нужны - тогда экстра это просто структура с вашими полями. Если поля неизвестны и могут меняться то иного способа кроме абстрактного списка логически вроде нет 0

@vxg Модератор 3409 / 2180 / 354 Регистрация: 13.01.2012 Сообщений: 8,461
	23.11.2016, 09:33
	Kastaneda, 1 верхний уровень хочет знать что то что не дает ему стандартная реализация. для этого мы делаем экстру. если экстра различная для разных реализаций нижнего уровня (что само по себе странно ибо как тогда работает верхний уровень если он не знает какие доп данные ему нужны), то можно на верхнем уровне различать экстры по типам. например экстра TCP или экстра UDP и соответственно по разному с ними работать. 2 если разработчик неадекват, то он может просто не использовать ваши данные. если есть желание защитить сами данные из-за того что они используются еще где-то в цепочке можно возвращать их не в структуре, а в объекте с доступом к полям через get функции. 0

@Kastaneda 5232 / 3205 / 362 Регистрация: 12.12.2009 Сообщений: 8,143 Записей в блоге: 2
	23.11.2016, 13:15 [ТС]
	IGPIGP, да, все верно. Грубо говоря AMQP при отправке ответа добавляет в ответ данные, по которым можно понять на какой именно запрос этот ответ. И это детали реализации AMQP. vxg, получается "кишками наружу") 0