держите и тестируйте на своем компиляторе:
http://liveworkspace.org/code/ca6c4fecda3d...d3101dcc94b165b (обновлено)

естственно все написанно на скорую руку и требует детальной доработки, но для работоспособности никакого буста не надо..
пример any  есть где то на форуме, но нужен только если, необходимо удлиненное хранение аргументов.. при ассинхронном подходе..
ну а кол-во аргументов можно расшить например до (входные const& , выходные&); чтоб была возможность диалога..

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


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


Это сообщение отредактировал(а) mes - 15.11.2011, 00:44

Если команды будут с 0..2 параметрами можно переписать так, что будет компилироваться в VS.
(уже сделали - не посмотрел на новую страницу темы)

Это сообщение отредактировал(а) math64 - 15.11.2011, 07:18

mes

Разобрался.
В конечном итоге решение сводиться к регистру шаблона команда со стандартным параметром void*, который в дальнейшем приводиться в соответствующий вид и передается конечному обработчику.
Теперь давайте поговорим о том, какое преимущество дает это решение?
Для каждой операции над объектом (а их много) необходимо создавать структуру параметров.
Каждую операцию надо регистрировать.
Каждая операция требует создания отдельного класса.
Усложненная реализация в плане понимания исходного кода.

Что я получаю взамен, чего мне не дает dynamic_cast? Как это решение облегчает дальнейшее сопровождение кода? Какие дает возможности расширения в будущем?
Я сам не люблю dynamic_cast, но в конечном итоге все делается для удобства написания и дальнейшего сопровождения. Я понимаю Ваше решение, но не понимаю какие плюсы мне это дает.
Не примите за критику, я пока просто пытаюсь понять плюсы предложенного решения  

Это сообщение отредактировал(а) azesmcar - 15.11.2011, 10:22

Для каждой операции над объектом (а их много) необходимо создавать структуру параметров.[/quote]

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

если не операцию,  а метод обработчика, то да.. 



не понимаю о чем Вы.. вот как выглядет пользование 



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


неправильная постановка вопроса.. это не альтернатива dynamic_cast, это просто иной подход к понятию интерфейс..


опять акцептирования внимание не на том.. dynamic_cast тут не при чем.. 


вот на это уже можно отвечать.. 
1. например у вас много обработчиков разных команд, (std::vector <handler_t*> v);
вы хотите в цикле для каждого вызвать команду move.. 
в случае с командами я напишу примерно так  :

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

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

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

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

и еще куча вариантов, на вспоминание которых  сейчас нет времени  

а теперь попробуйте переписать перечисленное через интерфейсы..

Добавлено через 5 минут и 37 секунд

советую также внимательнее рассмотреть моменты, которыми отличается предложенное решение от "классического" паттерна команда..

Добавлено через 7 минут и 43 секунды
и да и dynamic_cast никто не отменял, он остается как вариант взаимодействия обработчика с вариантами типов.. (или же вместо него будет визитор)..


Это сообщение отредактировал(а) mes - 15.11.2011, 10:51

Они практически все разнотипные.


Об этом



Для начала можно и не делить. В данном случае делить можно будет по необходимости. К примеру для начала создать интерфейс i_modifier, который будет содержать функции типа rotate, move, change_layer ... итд, а далее по необходимости реазделять на более мелкие интерфейсы.


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


Это уже другой разговор. Теперь давайте думать о том, нужно ли это?
В основном предполагается производить операцию над объектами через интерфейс базового класса.
Пример использования: пользователь выбрал несколько объектов и набрал команду move {10 20}, все объекты должны быть перемещены.
Того, что Вы описали не планируется, но я еще подумаю об этом.


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


Не нужно, эта возможность у нас уже есть. Все операции вызываются из команд, которые вызываются из интерпретатора. Для команд можно устанавливать pre/post callback-и.


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


А зачем нужно перекомпилировать чужую библиотеку в случае с интерфейсами?


далее другая группа делает следующее

зачем ей что-то перекомпилировать?

Кажется понял. Это вы про смену поведения для наших объектов? В общем-то этого нам тоже не нужно, они не имеют на это право. Другие могут только добавлять свои типы и операции, менять у нас они ничего не должны.

Еще раз скажу, что я не защищаю какое либо решение. Просто перед тем как принять одно, я должен понять что оно мне дает и чем я ради него жертвую.
На данный момент я нахожу наименьшим злом решение с query interface-ом, потому все предложения сравниваю с ним.  

Это сообщение отредактировал(а) azesmcar - 15.11.2011, 11:34

ну  ну.. успеха   что то после таких слов и не верится, что Вас пугает объем работы.. 


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


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


это называется игра в темную.. Если у вас уже есть команды то чего мы придумываем то тут ? 


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


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



появилась еще команда и в moveble добавили еще один метод..  

Добавлено через 1 минуту и 56 секунд

т.е. Вы заранее знаете как пользователю лучше ? 

Добавлено через 3 минуты и 1 секунду

при таком подходе я Вам не советчик..   

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


Я говорил не про регистрацию, а про то, что



Мы кажется друг друга не понимаем. Никто в чужие исходники не лезет. Зачем это нужно? Есть базовый класс geometry и некоторые операции типа move, rotate...которые определены в виде интерфейсов, другая команда разработчиков наследует свой тип, пусть будет rectangle и реализует интерфейсы move и rotate, о наших классах он ничего не знает, нашего кода у него нет и ему это не нужно.


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


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


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

давайте сравним.. 

пойдем разымышлять от QI : есть набор типов , которые поддерживают некоторые интерфейсы.. поддерживать они могут через множественноенаследование - что приводит к статическому монолиту, либо динамически региструя наследника, что позволяет расширять динамически поведение.. Если планируется расширение комманд и разрозренная разроботка (как в вашем случае) требуется второй вариант.. Для увелечения мобильности, интерфейсы должны быть минимализированы.. 
В принципе получили теже команды только в другом виде.. В чем же отличие ? В передачи действия :
представим картину.. мастеру пришло задание,   
QI :  он по одному вызывает рабочего, смотрит может ли он это выполнить , если да то дирижирует им.. 
Cmd :  письмо передается по очереди, в которой каждый выполняет лишь свое действие.. 

разница очень тонка в одном случае передается интерфейс в запрашиваемое место, в другом идет комманда до нужного интерфейса.. 
в обоих случаях они идут как (условно) void*,  в оноих для динамики надо регистрировать,


Это сообщение отредактировал(а) mes - 15.11.2011, 16:31

Нет, я знаю что он должен делать, а чего не должен  


А что не так с подходом? Я должен яростно защищать dynamic_cast? Тогда зачем создавать тему, если в итоге я все равно настроен решать так, как хочу сейчас?
Перед тем как принять решение, я должен понять его плюсы и минусы, и эти плюсы должны перевесить минусы.

mes

Давайте перед началом сравнения проясним кое-что. Я не нашел в Вашем примере где Вы вообще обрабатываете объекты? Вы вызвали обработчик, но где ему передается rectangle, polygon и тому подобное?
Этого здесь нет, как предполагается передача самого объекта обработчику?


Это сообщение отредактировал(а) azesmcar - 15.11.2011, 16:26

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

Добавлено через 3 минуты и 3 секунды

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

Это сообщение отредактировал(а) mes - 15.11.2011, 16:32

Вы насчет жертвы? А что Вы в этом нашли такого? Любой подход и любое решение - это плюс в одну сторону и минус в другую. Принятие минусов конкретного решения и есть эта жертва, сделанная ради ее плюсов.

Предлагаю такое решение: Вместо идентификатора у объект можно получить "пульт управления":

Я бы предпочел вариант,  "что я от этого выигрываю"... не говоря о слишком жестком акценте над словом "одно"...   

поэтому закуем в наручники 

Сорри за придирки, просто иначе не знаю варианта, как "заставить" Вас взглянуть под другим углом   

Одно - подразумевалось одно из решений.


С той же логикой можно отменить спецификаторы доступа. Долой private, делаем все методы и поля публичными  


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