Вопрос по архитектуре

Хранить enum с типом как то не хочется

Корень проблемы недоязычков :)

по моему мнению проблема кроется в этом:

Этого метода нет в интерфейсе IA, он намеренно скрыт

он намеренно скрыт

Чем скрыт?

s/foo(IA *a)/foo(A *a)

в том то и суть, чтобы IF не знал про IAF. Мне максимально нужно скрыть внутренности реализации. А наружу что бы вылазил интерфейсик, суть проблемы в том, что можно подсунуть левый самопальный класс...

И френд ещё. В общем, ты понел: паттерн «шаблонный метод».

там bar может принимать параметр, какой нибудь указатель на C, про который интерфейс не должен знать, это особенности внутренней реализации..

френд это все костыли...

Если б это был просто метод я бы вообще не парился )))

френд это все костыли...

забавно это читать в таком треде

придется извращаться:

struct IBar { virtual void bar(IA *a) = 0; virtual ~IBar() {} };

struct ABar : public IBar{
    void bar(IA *a){
        static_cast<A*>(a)->bar();
    }
}

.....

void IF::setBarExecuter(IBar *bar, int type){
........
}

// какое-то место где надо заюзаьт бар
auto barExecuter = getBarExecuter(a->getType());
if (barExecuter)
    barExecuter->bar(a);

Да-да, я уже понял, что это не сработает. Теперь думаю чуть дольше одной минуты.

И что-то я вижу такое:

1. A обязан знать про существование F, чтобы реализовать то, что ожидает F;
2. F обязан знать про существование A, чтобы вызывать foo() только для А;
3. F2 может не хотеть делать foo() для A;
4. чтобы это оставалось в рамках интерфейсов без кастов вслепую, все должны знать о существовании этого foo(), поведение которого зависит от реальных типов, скрытых за IF и IA.
5. foo() для A и F делает, что ему надо; для остальных — ничего.

Так что по идее правильным решением будет реализация double dispatch. То есть или enum, или dynamic_cast, или добавлять ещё по методу в IF и IA.

яркий пример. функция bar требует какой нибудь IDirectx11Device*. Я не хочу что бы интерфейс знал про этот класс, иначе юзеру придется качать SDK. Я делаю аналогичное но с openGL и хочу что бы юзер ничего не знал про GLuint хендлы, и что их можно биндить. Это использует отрисовщик, который скрыт во внутренней реализации.

Да придется мутить с enum-ом.

почему метод не должен быть в IA? а если действительно не должен, то зачем его вызывать у объекта? а если нужно вызывать, то зачем давать клиенту параметризировать именно объектом IA, а не A?

Не надо енумов, сделай нормально все, а не через пятую точку.

завели иерархию девайсов.

Если для IA нельзя сделать свою реализацию, то какой же это интерфейс? Так что скрытый метод надо перенести в IA в секцию protected, и спокойно вызывать в IF, зафрендив его.

тогда придется инклудить какойнить DirectXSDK.h (это я к примеру), и клиенту качать СДК...

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

PIMPL

Да ничего не придеться там инклудить. И френд тоже не нужен.

Еще в IF есть какой-то метод foo(IA *a). Внутри он преобразуется static_cast-ом в A и у него вызывается какой-то метод. Этого метода нет в интерфейсе IA, он намеренно скрыт и используется только внутри класса F в реализации.

Это извращение;-)

И F и A знают что то, что не должен знать никто снаружи, при этом A должен передаваться через эту самую наружу, но не должен выглядеть как A (потому что его там не видно)?

Либо делайте это хозяйство виртуальным и юзайте RTTI (dynamic_cast), либо заводите например таблицу видную тока A и F, кладите туда пойнтер на A и передавайте id таблицы. Есть еще много всяких извратных решений наверное, но:

программист может определить класс AA, который наследует интерфейс IA

«Можно придумать защиту от дурака, но только от неизобретательного»(ц)

почему метод не foo(A *)?

Может стоит немного изучить язык, которым пользуешься? Для передачи A* клиенту не нужно знать A, достаточно forward declaration. Так что IA тут не нужен

У тебя параллельная иерархия. Не гуд.

Блина... и кстати да, а я туплю!;-(((

Для передачи A* клиенту не нужно знать A, достаточно forward declaration

Самый годный коммент во всей ветке;-)

Архитектура? Нет, не слышал.

где же это годный коммент? Ну представь что IF принимает foo(A *a), A = forward declaration. этот самый IF может конструировать IA, так как же мы IA передадим в метод foo?

// IA нихера не должен знать про детали типа hiddenMethod
struct IA{
    virtual void setSomething(int i) = 0;
    virtual ~IA() {}
}

struct IF{
    virtual IA *makeA() const = 0;
    virtual void drawA(IA *a) = 0;
    virtual ~IF() {}
}

struct ConcreteA : public IA{
    virtual void setSomething(int i) { ... }
    void hiddenMethod(SomeHidden *sh) { ... }
}

struct ConcreteF : public IF{
    ConcreteF() { m_sh = new SomeHidden(); }
    virtual IA *makeA() const { return new ConcreteA(); }
    virtual void drawA(IA *a) { 
        static_cast<ConcreteA*>(a)->hiddenMethod(m_sh); 
        // правильно избавится от static_cast
        // юзер может определить свой наследованный от IA класс
        // и попытаться запихать его в этот метод
    }
    SomeHidden *m_sh;
}

int main(){
    IF *f = new ConcreteF();
    IA *a = f->makeA();
    a->setSomething(100500);
    f->drawA(a);
    delete a;
    delete f;
    return 0;
}

А dynamic_cast просто так придумали?

IA может наследовать ConcreteA1, ConcreteAB так чтоже, мне на все случаи жизни делать getConcreteA1Ptr, getConcreteANPtr ?

медленно. В игровом цикле не гуд делать

Либо делайте это хозяйство виртуальным и юзайте RTTI (dynamic_cast)

Вопрос по архитектуре (комментарий)

Я так понял, что ТС религия не позволяет его использовать;-)

1-3х тактов жалко? А танцы с бубеном вокруг енума или его аналогов думаете быстрее будут?

да, скорость не просела с dynamic_cast-ом, но что-то религия не позволяет его использовать ))))

«Доктор, вы уж определитесь, или туда, или сюда»(ц)

Если хочется сделать красиво - есть динамик_каст, это самое прямое. Если хочется сделать быстро - или статик_каст, или завести скажем в IA поле A* Aptr и его инициализировать правильно. А если хочется и быстро и красиво, да еще с такой архитектурой, так меняйте ЯП;-)

Принимайте буддизм, там все можно;-)

Страуструп, против этого.. )) так и придется костылять с каким нибудь dynamic_cast-ом или заранее оговорить что левоту пихать не надо )))

Суть вопроса. static_cast в данном контексте зло,

Делай в отладочной версии dynamic_cast с проверкой успешности приведения, а в релизной версии static_cast, и будет тебе спокойно на душе.

А если хочется и быстро и красиво, да еще с такой архитектурой, так меняйте ЯП;-)

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

Да какой нить кодогенератор на каком нить лиспе наверное;-)))

Знал бы - уже бы сам поменял;-(

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

+1

/thread

dynamic_cast ?

Ты неправильно спроектировал систему и мучаешься теперь. Если интерфейсы не получается использовать как интерфейсы, значит ты ошибся. Можно пример не абстрактный?

Твой ConcreteF не является IF, так как не умеет draw'ить IA.

Я не знаю, что там у тебя за конкретные задачи, но скорее всего тебе нужен паттерн «мост» + pimpl.

man dynamic_cast /thread

и вообще

Внутри он преобразуется static_cast-ом в A и у него вызывается какой-то метод. Этого метода нет в интерфейсе IA, он намеренно скрыт и используется только внутри класса F в реализации.

Костыли вы мои костыли, дайте я вас сейчас расцелую.
КостыльнЫе мои костыли, костыли костыли костыли костыли.

Или ещё вот тема есть:

Ехал Грека через реку,
Видит Грека в реке костыль.
Сунул Грека в реку костыль,
Костыль костыль костыль костыль.