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).