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

КЛ>>Есть иерархия полиморфных объектов, которые отображаются в комбобоксе. При изменении текущего объекта в комбике надо апдейтать UI(кнопочки, радиобаттоны и т.п.). Вот для этой хрени я и заюзал визиторов. Иерархия состоит из 3х(!) классов. И вот из-за них я и замутил все это дело с визиторами. Скажешь зачем, ведь проще было if'ов напихать? Да, проще, но я решил что:
КЛ>>а) так красивее (просто мне нравится!)
КЛ>>б) потом если придется добавить 4, 5, 6 класс я пойму, что сделал правильный выбор.

КЛ>>НО, у visitors есть свои нехилые недостатки (взаимозависимости) и никто не говорит о том, что это панацея.

L>Насколько я помню visitor как раз удобен там где иерархия классов в будущем не будет изменяется, а будут только добавляться новые операции. Так что слова о 4,5,6 классе звучат странно.

Не совсем. Добавление нового класса влечет за собой добавление новых методов void Visitor::Visit( SomeNewType& ); void SomeNewType::Accept( Visitor* ).
При этом меняется только интерфейс Visitor'а. Новые операции появляются за счет создания наследников Visitor'а. Так что о не применимости этого паттерна к иерархии, которая изменяется( в большинстве же случаев она разрастается ) не совсем корректно. Как раз о ее применимости и пишет господин А.
Кстати, она у меня скорее всего не изменится никогда.