[C++] Interfaccia estesa e RTTI

[giuseppe500]

ciao.
Ho degli oggetti commands che eseguono delle azioni(chiamando la funzione execute) su di un CElementBase da cui derivano tutte le entità del mio progetto.
Il problema è che alcuni command sono specifici di un entità e non di un altra.
Se io stabilisco tutte le possibili funzioni virtuali nel CElementBase risolverei implementando o non implementando nella classe derivata le funzioni a seconda
del tipo.
Il problema è che in queto modo l'interfaccia cresce significatamente (quali sono i problemi relativi ad un interfaccia grande?) e poi non è
corretto semanticamente , perchè le funzioni non usate non sono specifiche della classe base, è un metodo usato lo stesso?

Ho gia fatto una discussione incentrata pero' sul composite e la classe node comune.
una soluzione spiegatami allora da shodan credo fosse usare l'rtti o un rtti dei poveri(una stringa che identifica il tipo).
e che la scelta dipende dal caso specifico.

Intanto non ho capito:
1)cosa da l'rtti di piu'che una stringa con il tipo , e poi mi sembra che vada attivato nelle proprietà del progetto è vero?
2)in base a cosa sceglier su un interfaccia grande o l'uso dell rtti? o stringa di tipo?

[shodan]

Originariamente inviato da giuseppe500
1)cosa da l'rtti di piu'che una stringa con il tipo

Funziona anche con i tipi base. Prova a implementare l'altro modo in qualcosa che non sia una classe (un int ad esempio).
A livello di velocità l'RTTI nativa è meno veloce di un metodo virtuale, ma per lo meno non è soggetta a errori introdotti dal programmatore.

e poi mi sembra che vada attivato nelle proprietà del progetto è vero?

In VS è attivata di default (come credo in tutti i compilatori C++ standard). E' comunque possibile disabilitarla.

Ho degli oggetti commands che eseguono delle azioni(chiamando la funzione execute) su di un CElementBase da cui derivano tutte le entità del mio progetto.
Il problema è che alcuni command sono specifici di un entità e non di un altra.

E Quindi? Non ti basta invocare execute() che a sua volta richiama le funzioni non virtuali?

quali sono i problemi relativi ad un interfaccia grande?

Di solito un'interfaccia enorme è sintomo di un errore in fase di design (fase troppo spesso sottovalutata).

[giuseppe500]

Ho degli oggetti commands che eseguono delle azioni(chiamando la funzione execute) su di un CElementBase da cui derivano tutte le entità del mio progetto.
Il problema è che alcuni command sono specifici di un entità e non di un altra.

non ho spiegato bene il problema ,non ho detto tutto.
gli oggetti commands vengono creati alla pressione di un button widget tramite una funzione clone dal tipo incapsulato in quel button, tipo il pattern prototype.

una volta creato l'oggetto command viene reso il current command e riceve gli input o le azioni relative dal mouse e dalla tastiera e lavora su uno o piu currentelement ereditati da CElementBase che vengono settati tramite piking o selezione dalla finestra opengl.

E' per questo che penso di risolvere nelle classi command testando se il current element è di tipo supportato ma è la parte piu brutta del mio design, ti chiedevo se si puo fare qualcosa di meglio.

ciao.
grazie.

[shodan]

Originariamente inviato da giuseppe500
gli oggetti commands vengono creati alla pressione di un button widget tramite una funzione clone dal tipo incapsulato in quel button, tipo il pattern prototype.

Questo chiarisce alcune cose, ma non cambia molto le carte in tavola.
Per come la vedo io, in questo caso l'errore di design è proprio creare una "big interface" omnicomprensiva, visto che alla fine ti ritrovi con un sacco di metodi vuoti solo per accontentare tale interfaccia. Un metodo del genere può andare bene quando hai una o due classi il cui metodo deve restare vuoto, ma tutte le altre no. Stesso discorso per i metodi in se: se hai due classi, di cui una avrà metà metodi vuoti per soddisfare l'interfaccia significa che qualcosa non va.

E' per questo che penso di risolvere nelle classi command testando se il current element è di tipo supportato ma è la parte piu brutta del mio design, ti chiedevo se si puo fare qualcosa di meglio.

No. In ogni caso sei costretto a fare un downcast visto che passi/ricevi un puntatore base.
Il massimo che potresti fare è usare delle sotto interfacce di aggregazione logica. Mi spiego: se dal tuo CElementBase derivi che so, rettangolo giallo, rettangolo rosso, quadrato giallo, quadrato verde, puoi introdurre sotto interfacce rettangolo e quadrato e da queste derivare poi gli oggetti concreti. In fase di downcasting ricaverai le interfaccie rettangolo e quadrato e non i singoli oggetti rettangolo rosso o quadrato verde. Questo potrebbe portare a una semplificazione in fase di downcasting, ma è da vedere se è applicabile al tuo caso.
In definitiva questo è lo stesso principio (seppure con le dovute differenze di implementazione) delle interfaccie COM. Tutti i puntatori restituiti da COM sono IUnknown che poi vengono trasformati nell'interfaccia richiesta tramite un brutale casting controllato.
Direi comunque che il metodo RTTI "dei poveri" sia il più indicato in questo caso (meglio però restituire un intero e non una stringa).