[C++/OO] Oggetti dentro una classe: possono comunicare con quest'ultima?

[Duchamp]

Saluto tutti e mi scuso per l'orribile titolo, non sono riuscito a trovare niente di stimolante!
Arrivo al dunque: ho una classe che, con un vector, raccoglie una serie di puntatori ad altri oggetti. Questa classe "madre" ha anche una variabile pubblica. La mia domanda: uno qualsiasi degli oggetti del vector può accedere a quella variabile pubblica? Se sì, come?
Come sempre grazie per la disponibilità! ;)

[DanieleC88]

Se il vector contiene puntatori ad oggetti, devi trovare il modo di collegarli alla classe "madre" che fa da contenitore. A quel punto sì, se il membro è pubblico potrai accedervi anche da lì, altrimenti puoi promuoverlo a protected e rendere friend le classi che infili nel vector. Ma mi sa comunque di zozzata. :p

[Duchamp]

Ma mi sa comunque di zozzata. :p

Chiamiamolo "workaround" che fa più figo :p
Intanto grazie per la risposta! Però aggiungo un pezzo: se la classe madre non ha nessuna parentela con gli oggetti inclusi nel vector (ovvero sono tipi differenti) il tuo suggerimento rimane valido?

[!k-0t1c!]

Non c'è verso di fare quel che vuoi se il contenuto non conosce il contenitore.
Pensa a un vettore di string. std::string rimane invariata e non conosce il vettore, né tantomeno un'eventuale classe con riferimento al vector stesso.
C'è un problema non indifferente, in tutto questo: in C++ quel che vuoi fare crea una dipendenza circolare, che come in qualunque classe di ingegneria del software ti insegnano, è da evitare come la peste. In altri linguaggi l'uso di un'interfaccia potrebbe salvarti ma qui ti consiglio un redesign in cui i contenuti non abbiano necessità di conoscere il contenitore.

[tomminno]

In altri linguaggi l'uso di un'interfaccia potrebbe salvarti ma qui ti consiglio un redesign in cui i contenuti non abbiano necessità di conoscere il contenitore.

E perchè mai in C++ l'utilizzo di un'interfaccia "non lo salverebbe"?
Sicuramente il design può essere rivisto ma non vedo il problema delle interfacce per il C++.

[!k-0t1c!]

E perchè mai in C++ l'utilizzo di un'interfaccia "non lo salverebbe"?
Sicuramente il design può essere rivisto ma non vedo il problema delle interfacce per il C++.
Perche C++ non ha il concetto di interfaccia, e una classe astratta dove tutti i metodi sono pure virtual resta un hack con alcuni svantaggi.

[tomminno]

Perche C++ non ha il concetto di interfaccia, e una classe astratta dove tutti i metodi sono pure virtual resta un hack con alcuni svantaggi.

Svantaggi del tipo?
A tutti gli effetti si comporta come un'interfaccia.

[PGI-Bis]

Ma soprattutto, che c'entra tutto questo con la programmazione OO?

[DanieleC88]

Ma soprattutto, che c'entra tutto questo con la programmazione OO?
Forse gli servirà per OpenOffice.
O forse simboleggia i due maroni che gli fa il C++.

[!k-0t1c!]

Svantaggi del tipo?
A tutti gli effetti si comporta come un'interfaccia.
Il caso più banale è quello dell'ereditarietà multipla. In C#/Java/... si eredita da al max 1 classe e quante interfacce si vuole. Con il fatto che in C++ non esiste il concetto di interfaccia uno potrebbe modificare la classe usata come interfaccia e fornire implementazioni che non sono coerenti con tutte le classi che ereditano dall'interfaccia stessa e che potrebbero venire inavvertitamente usate da altro codice causando bug di difficile individuazione.
Un altro scenario molto banale: RTTI per testare la presenza o meno di un'interfaccia...
Ce ne sono molti altri, più o meno insidiosi.

[tomminno]

Il caso più banale è quello dell'ereditarietà multipla.


E dove starebbe il problema? Non sei mica obbligato ad usarla. Non lo vedo certo come un problema per l'utilizzo delle interfacce in C++, specialmente nel caso in esame.


Con il fatto che in C++ non esiste il concetto di interfaccia uno potrebbe modificare la classe usata come interfaccia e fornire implementazioni che non sono coerenti con tutte le classi che ereditano dall'interfaccia stessa e che potrebbero venire inavvertitamente usate da altro codice causando bug di difficile individuazione.


Se uno lo fa evidentemente sa a cosa va incontro.
E perchè mai uno non potrebbe creare l'interfaccia e poi una classe base per le implementazioni dell'interfaccia ed ereditare da quella classe?
Avresti lo stesso problema? No.
Ancora una volta non vedo il problema, nè tanto meno applicato al caso in esame.


Un altro scenario molto banale: RTTI per testare la presenza o meno di un'interfaccia...
Ce ne sono molti altri, più o meno insidiosi.

A che serve testare la presenza di un'interfaccia tramite typeid?
Basta usare dynamic_cast se quanto ottenuto è NULL allora non c'è.
Inoltre non credo che in questo caso verrà mai usato in una qualunque forma RTTI.

[marco.r]

Il caso più banale è quello dell'ereditarietà multipla. In C#/Java/... si eredita da al max 1 classe e quante interfacce si vuole. Con il fatto che in C++ non esiste il concetto di interfaccia uno potrebbe modificare la classe usata come interfaccia e fornire implementazioni che non sono coerenti con tutte le classi che ereditano dall'interfaccia stessa e che potrebbero venire inavvertitamente usate da altro codice causando bug di difficile individuazione.
Un altro scenario molto banale: RTTI per testare la presenza o meno di un'interfaccia...
Ce ne sono molti altri, più o meno insidiosi.

Concordo con quanto gia' esposto da tommino, e aggiungo: se anche fosse, che problema insormontabile causa nel contesto della domanda dell'autore del thread ?

[!k-0t1c!]

Il problema non emerge direttamente, ma a seconda della natura del progetto può presentarsi benissimo in altri momenti e, se ci sono, con altri sviluppatori del progetto. In Java/C# se uno implementa in una classe astratta un'interfaccia e poi eredita dalla classe astratta si è scelto l'unica classe da cui può ereditare. In c++ questo non funziona. E in C++ come potrebbe poi dirsi ben definito il caso in cui una eredita da una classe astratta che implementa alcuni metodi di un'interfaccia ed eredita (diciamo per una svista) anche da un'altra classe che implementa la medesima interfaccia?
All in all a me sembra una soluzione sporca quella in C++, ma quel che importa è che siamo OT :)

[tomminno]

Il problema non emerge direttamente, ma a seconda della natura del progetto può presentarsi benissimo in altri momenti e, se ci sono, con altri sviluppatori del progetto.


Che è una considerazione che va oltre la richiesta del thread.


In Java/C# se uno implementa in una classe astratta un'interfaccia e poi eredita dalla classe astratta si è scelto l'unica classe da cui può ereditare. In c++ questo non funziona.


E perchè no? Funziona ugualmente. Non sei obbligato ad usare l'eredità multipla.


E in C++ come potrebbe poi dirsi ben definito il caso in cui una eredita da una classe astratta che implementa alcuni metodi di un'interfaccia ed eredita (diciamo per una svista) anche da un'altra classe che implementa la medesima interfaccia?


Per svista? Ottieni uno warning che ti avvisa che l'interfaccia è già implementata dall'altra classe base e viene richiamato comunque il metodo della classe in esame.


All in all a me sembra una soluzione sporca quella in C++, ma quel che importa è che siamo OT :)


Boh a me sembra che la soluzione sia "sporca" al di là del linguaggio.
La soluzione corretta è rivedere il design.

[!k-0t1c!]

Che è una considerazione che va oltre la richiesta del thread.

Certo, ma vogliamo dare consigli completi, no? Non certo qualcosa che funziona contingentemente e può causare facilmente altri problemi.


E perchè no? Funziona ugualmente. Non sei obbligato ad usare l'eredità multipla.

Certo, ma un conto è non dovere, un conto è non potere.



Per svista? Ottieni uno warning che ti avvisa che l'interfaccia è già implementata dall'altra classe base e viene richiamato comunque il metodo della classe in esame.

Interessante, non sapevo :) Chissà di che livello è considerato il warning. Ad ogni modo idealmente andrebbe riportato come errore. Stento a immaginare un design corretto dove un caso del genere possa essere indispensabile o inevitabile.


Boh a me sembra che la soluzione sia "sporca" al di là del linguaggio.
La soluzione corretta è rivedere il design.
Su questo siamo perfettamente d'accordo! :)

[banryu79]

Interessante, non sapevo :) Chissà di che livello è considerato il warning. Ad ogni modo idealmente andrebbe riportato come errore. Stento a immaginare un design corretto dove un caso del genere possa essere indispensabile o inevitabile.

Sì ma il compilatore deve badare alle faccende riguardanti il linguaggio, non a presunti errori di design... e ci mancherebbe altro! :D