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

@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.
Важно ещё проанализировать количество различных состояний дифференцируемых на предмет обработки ответа, чтобы понять какой длины поле следует выбрать.

Новые блоги и статьи Все статьи Все блоги /
WordPad для Windows 11 Jel 10.01.2026 WordPad для Windows 11 — это приложение, которое восстанавливает классический текстовый редактор WordPad в операционной системе Windows 11. После того как Microsoft исключила WordPad из. . .	Classic Notepad for Windows 11 Jel 10.01.2026 Old Classic Notepad for Windows 11 Приложение для Windows 11, позволяющее пользователям вернуть классическую версию текстового редактора «Блокнот» из Windows 10. Программа предоставляет более. . .	Почему дизайн решает? Neotwalker 09.01.2026 В современном мире, где конкуренция за внимание потребителя достигла пика, дизайн становится мощным инструментом для успеха бренда. Это не просто красивый внешний вид продукта или сайта — это. . .	Модель микоризы: классовый агентный подход 3 anaschu 06.01.2026 aa0a7f55b50dd51c5ec569d2d10c54f6/ O1rJuneU_ls https:/ / vkvideo. ru/ video-115721503_456239114
Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ФедосеевПавел 06.01.2026 Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ВВЕДЕНИЕ Введу сокращения: аналоговый ПИД — ПИД регулятор с управляющим выходом в виде числа в диапазоне от 0% до. . .	Модель микоризы: классовый агентный подход 2 anaschu 06.01.2026 репозиторий https:/ / github. com/ shumilovas/ fungi ветка по-частям. коммит Create переделка под биомассу. txt вход sc, но sm считается внутри мицелия. кстати, обьем тоже должен там считаться. . . .	Расчёт токов в цепи постоянного тока igorrr37 05.01.2026 / * Дана цепь постоянного тока с сопротивлениями и напряжениями. Надо найти токи в ветвях. Программа составляет систему уравнений по 1 и 2 законам Кирхгофа и решает её. Последовательность действий:. . .	Новый CodeBlocs. Версия 25.03 palva 04.01.2026 Оказывается, недавно вышла новая версия CodeBlocks за номером 25. 03. Когда-то давно я возился с только что вышедшей тогда версией 20. 03. С тех пор я давно снёс всё с компьютера и забыл. Теперь. . .

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

@vxg Модератор 3407 / 2178 / 354 Регистрация: 13.01.2012 Сообщений: 8,448
	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 Модератор 3407 / 2178 / 354 Регистрация: 13.01.2012 Сообщений: 8,448
	22.11.2016, 14:19
	Kastaneda, если объект 1-го уровня может вызвать обработчик объекта 2-го уровня во время приема данных (вместо вызова обработчика неким стандартным механизмом) и передать в этом обработчике нужные данные наверное это самое естественное решение кроме кэша 0

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

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

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

@vxg Модератор 3407 / 2178 / 354 Регистрация: 13.01.2012 Сообщений: 8,448
	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