кто то кого то не понимает или оба друг друга.. 

Это сообщение отредактировал(а) math64 - 11.11.2011, 10:01

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

Я наверное не поняла всю сложность задачи,.. потому что по-моему все просто. Каждому типу объекта задается уникальный идентификатор. Далее регистрируем наборы функций для каждого типа (устанавливаем соответствие идентификатор-типа -> функция-делания-чего-то). Теперь общая функция, например copy, будет смотреть, какой объект к ней пришел, и вызывать соответствующую ему функцию копирования или пытаться выполнить какую-то операцию по умолчанию (попытаться самой провести копирование, или бросить эксепшн Ахтунг, или еще что-нибудь).

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

еще одно, делите на слои..  так для визуального редактора явно выделяются два :
модели фигур и контролеры их взаимодействия с пользователем.. 
соотношение сущностей не прямое.. то есть на каждую фигуру свой контролер - плохо..

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

если смешаете обработку команд и логику фигур в одно месиво, да придется.. (только я этого не предлогал)

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

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

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

math64
Этих IMovable, IRotatable и всего остального будет слишком много, чтобы пихать их в параметры функции.


Мне самом не нравится, просто интересует и Ваше мнение. Мне оно не нравится по той же причине.


Про какую?  


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


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

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

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

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

Можешь реализовать и с отдельными visit(IMovable), visit(IRotatable), и т.д.  - eсли не смущает то, что если объект поддерживает несколько интерфейсов, visit() придётся вызывать несколько раз, по разу для каждого интерфейса.
Главное определить набор интерфейсов так, чтобы при добавлении нового класса не нужно было добавлять нового интерфейса.

Такое ощущение, что кто-то недавно прочитал про Visitor и сразу бросился им загромождать код. -) Уж извините, такое впечатление сложилось.

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


если методы добавляются редко лучше использовать visitor. query interface-подобные решения не дают возможности привычного статического контроля.


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

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

мне нравится способ, примененный в boost::operators.

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

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


не совсем понял.


имелось ввиду, что и классов и функций достаточно много.


т.е. Вы за

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


Вы про CRTP? А как это здесь поможет?

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


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

Ты не связан статической системой типов языка. Ты сделаешь свою маленькую динамическую.

Читал котда-то давно статью в "Мир ПК", в каком номере не помню, про модифакцию патерна Visitor с возможностью добавления новых посещаемых классов, но реализация довольно сложная - для того, чтобы пользоваться новыми классами в модифицированном Visitor. их нужно регистрировать.

Регистратор прикрутить как раз несложно. Но проблема в том, что при добавлении нового типа объектов, существующие визиторы о них ничего не узнают (кроме факта существования, регистрация ничего не добавит). Как сделать DoSomething с объектом неизвестной породы? Только вызвать его соответствующий виртуальный метод. А методы плодить на все случаи жизни не хочется. Можно сделать что-то типа Invoke с параметром "заданное действие". И пусть объект решает, поддерживает он это действие или ну его нафик. Вот только действие передавать придется либо идентификатором, либо каким-то классом-тэгом и в конечной реализации возникнут if или switch...