Хочу сделать разную реакцию программы на получение ответа от сервера на разные типы запросов. Очередь запросов представлена подобным образом:

// псевдокод




Ответ от сервера приходит в один метод типа:



Думал сделать както-то так:



Но я бы хотел иметь возможность точно определять какого типа объект класса в рантайме. Как я понимаю это единственный вариант при использовании примера выше без использования RTTI:



У кого есть мысли как это лучше организовать?

Для dynamic_cast используется RTTI. В вашем случае для doStuff..() он не нужен, проще и правильнее организовать специфичные действия прямо в виртуальном do(). Лично я использую проверку на тип только в таких случаях:



То есть проверяю принадлежность объекта к текущему наследованному типу.

зачем очередь представлена как вектор?... впрочем, не так и важно.
без RTTI - можно ввести поле enum в AbstractRequest и по нему ориентироваться, т.е. без dynamic_cast<>.
Нечто вроде:
1) класс RequestFile, RequestHtml наследники от AbstractRequest , получают данные в методе do().
2) классы обработчики реквестов, их экземпляры подтягиваются в конце do() (ну или у вас где dinamic_cast) через фабрику.. вот тут можно разрулить - подтягивать ли фабрикой новые экземпляры обработчиков, или выдавать singleton-ы.... Фабрика может судить о том что ей создать исходя из поля в AbstractRequest 

Сумбурно как-то.. но наверно можно развить идею

Вот оно как...

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

SABROG, тебе не кажется, что этот вопрос в данном разделе не очень уместен?   

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

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


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



Или ты имеешь ввиду шаблонные классы с типовой специализацией?

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

Я понял, но нужно рассмотреть несколько реализаций фабрик, которая мне бы подошла, а то ведь тот же паттерн Factory завязывается на виртуальном наследовании, а у меня тут поле Type. Я где-то видел фабрику, которая генерила объекты по строковому параметру типа f->create("automobile"), вероятно мне придется сделать что-то похожее, но типа такого f->create(Request::HtmlPage), ну и request->doStuff().

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

Это сообщение отредактировал(а) jonie - 25.5.2010, 21:16

Значит я все-таки не до конца тебя понял. Ты предлагаешь оставить структуру как есть, но добавить класс, который будет "плодить" функторы разных классов в зависимости от Type'a?


Abstract Factory

yes.  собственно фабрику. Пост мой прочти этот [http://forum.vingrad.ru/index.php?showtopic=301427&view=findpost&p=2158864]  - не нужны будут if-ы, в фабрике можно использовать std::map, да и вообще кастомизировать этот твой if по Type-у как угодно сложно\легко (заивист от фантазии).

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

замечу что "абстактная фабрика" ничуть не называется "фабрика" 8-)

Почитал документацию к примерам фабрик PapaFactory и дошел до такого текста:



То есть у меня вообще 2 выходит. Как бы там ни было продолжу копать в направлении фабрик для саморазвития и возможности расширения функционала кода в перспективе.