BZ>затем, что они несовместимы со старым интерфейсом, в который добавлен новый параметр
Добавлять новые параметры (или иным образом изменять оные), конечно же, нельзя. Но в хорошо спроектированном интерфейсе это не требуется. Но можно добавлять новые методы в интерфейс, в крайнем случае, заводить новые версии существующих методов.

Здравствуйте, AndreyM16, Вы писали:

AM>Возникли вопросы про сабжу. Как это можно сделать и вообще правильно ли это? По мне так такая штука очень полезная, например есть набор модулей с общим интерфейсом, которые общаются через сообщения, но данные в сообщениях могут быть разного типа и их количество(типов данных) может со временем расти или в том же обзёрвере в его push варианте. Может быть такое возникает при ошибках проектирования или это нормальная ситуация?
Идея хорошая и при качественной реализации дает стабильный редкоизменяемый каркас с развитием в виде модулей расширения.
Беда тут в том что сделать такой каркас очень непросто и проблем там гораздо больше чем просто правильно выбрать тип сообщения и интерфейс.
Я принимал участие в нескольких таких попытках. И как минимум одну из них можно назвать успешной.
Это интересно для разработчика но очень рисковано для заказчика и наверно поэтому встречается нечасто.
Ведь в большинстве случаев можно взять готовое решение.
Я бы порекомендовал поглядеть на Apache ActiveMQ.
Даже если решите строить свою систему там есть на что посмотреть

Короче, Склифосовский (с), ты лучше пальцем покажи (с)
Можешь на простом простом примере продемонстрировать свое решение, а то XML , tabi. Посмотрел я tabi, так и не понял как его можно приложить, дa и XML тоже

Здравствуйте, AndreyM16, Вы писали:

AM>Здравствуйте!

AM>Возникли вопросы про сабжу. Как это можно сделать и вообще правильно ли это?

Насчет можно можно посмотреть, например, google::protobuf. Не идеально, но работает.

А вообще, наверно, правильно

Здравствуйте, Vamp, Вы писали:

V>Добавлять новые параметры (или иным образом изменять оные), конечно же, нельзя. Но в хорошо спроектированном интерфейсе это не требуется.

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

Здравствуйте, qqqqq, Вы писали:

Q>Короче, Склифосовский (с), ты лучше пальцем покажи (с)
Q>Можешь на простом простом примере продемонстрировать свое решение, а то XML , tabi. Посмотрел я tabi, так и не понял как его можно приложить, дa и XML тоже

читай книги по xml. tabi используется в freearc

Здравствуйте, BulatZiganshin, Вы писали:

BZ>Здравствуйте, Vamp, Вы писали:

V>>Добавлять новые параметры (или иным образом изменять оные), конечно же, нельзя. Но в хорошо спроектированном интерфейсе это не требуется.

BZ>это хорошо, что у вас в архитекторы берут только ясновидящих 3-го класса. ну а мы в провинции по старинке пишем расширяемые интерфейсы

Здравствуйте, hramovnik, Вы писали:

H>Здравствуйте, BulatZiganshin, Вы писали:

BZ>>Здравствуйте, Vamp, Вы писали:

V>>>Добавлять новые параметры (или иным образом изменять оные), конечно же, нельзя. Но в хорошо спроектированном интерфейсе это не требуется.

BZ>>это хорошо, что у вас в архитекторы берут только ясновидящих 3-го класса. ну а мы в провинции по старинке пишем расширяемые интерфейсы

А версионирование интерфейсов, как в СОМ, не устраивает?

Здравствуйте, hramovnik, Вы писали:

H>А версионирование интерфейсов, как в СОМ, не устраивает?

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

Здравствуйте, BigBoss, Вы писали:

BB>Насчет можно можно посмотреть, например, google::protobuf. Не идеально, но работает.

это как раз сериализация. бинарная, но расширяемая, как xml. аналогичный проект есть у facebook, но там упор на RPC

Здравствуйте, BulatZiganshin, Вы писали:

BZ>Здравствуйте, hramovnik, Вы писали:

H>>А версионирование интерфейсов, как в СОМ, не устраивает?

BZ>это хорошо, если новые версии появляются редко и одна из сторон (клиенты или серверы) имеется в единственном экземпляре. представь десяток серверов, десяток клиентов и каждый месяц появляется новый параметр, который один из этих клиентов хочет передавать одному из серверов

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

Или предполагается независимое развитие каждого из серверов?

Здравствуйте, hramovnik, Вы писали:

H>Столь активное обновление меня настораживает.

обычное развитие. сейчас и новую. версию выпускать ежемесячно несложно

H>В любом случае будут необходимы изменения и на клиенте и на сервере, так что не вижу проблем.

я имел в иду необязательные параметры, хинты. нарпимер сколько потоков/памяти использовать

H>Или предполагается независимое развитие каждого из серверов?

да, а что тут такого. в один добавлены одни новые фичи, в другой другие. а клиенты общие

Здравствуйте, BulatZiganshin, Вы писали:

BZ>Здравствуйте, Mr.Delphist, Вы писали:

AM>>>А вообще, потребность в этом не ошибка проектирования?

MD>> — полностью согласен. Сколько раз сталкивался с таким, всё равно этот "произвольный объект" и финальный свитч "по типам" в конце концов заменялся на иное решение, более "прямого" характера. Поэтому — не тратьте время, если нет горящего дедлайна. Обдумайте спокойно: как можно генерализовать необходимые операции? зачем понадобился этот нашлёпок с "любым типом"?

BZ>для расширяемости. например поддержки в сервере новой операции без переделки старых клиентов, её не использующих. странно, что ты проспал использование xml, например, для этих целей

Честно говоря, не понял, кому адресовано выделенное. Ну да ладно.

Вот именно XML-based решения — один из ярких примеров генерализации, безо всяких нашлепков. Есть единый API между клиентом и сервером, внутри дергается парсер-фабрика, порождающая далее нужное инстанциирование и т.п. Парсинг свалился — возвращем ошибку. Постепенно начинаем понимать, что "наивный" XML с захардкоживанием туда жестких структур и путей — тот же свитч по типам, "только сбоку" (с). Думаем. Далее генерализуем структуру XML (например, делаем тот же property bag). Парсер упрощается, интерфейс единый, профит (с).

И никаких boost::any или VARIANT.

Здравствуйте, Mr.Delphist, Вы писали:

MD>>> — полностью согласен. Сколько раз сталкивался с таким, всё равно этот "произвольный объект" и финальный свитч "по типам" в конце концов заменялся на иное решение, более "прямого" характера. Поэтому — не тратьте время, если нет горящего дедлайна. Обдумайте спокойно: как можно генерализовать необходимые операции? зачем понадобился этот нашлёпок с "любым типом"?

BZ>>для расширяемости. например поддержки в сервере новой операции без переделки старых клиентов, её не использующих. странно, что ты проспал использование xml, например, для этих целей

MD>Честно говоря, не понял, кому адресовано выделенное. Ну да ладно.

MD>Вот именно XML-based решения — один из ярких примеров генерализации, безо всяких нашлепков.

xml — это и есть один из способов кодирования произвольного типа. неэффективный, зато "из коробки". если тебя это не устраивает, ты модешь взять бдолее эффективную библиотеку сериализации/rpc или написать свою