Ereditarietà multipla

[atragon]

Domanda frutto di una chiaccherata con alcuni sviluppatori. Mio quesito: come mai in tanti linguaggi moderni si tende a non supportare l'ereditarietà multipla? Per quanto ne so tra quelli "diffusi" solo C++ e Smalltalk la supportano, anzi anche Python se non erro... Delphi, Java, C#, per non parlare di VB, per citarne altri, invece no. Alcune idee:
"ci sono le interfaccie che bastano e avanzano". Può darsi che bastino ma non mi sembra proprio la stessa cosa
"troppo complessa e soggetta a bug la programmazione". Questo mi sembra più sensato ma poichè non lo dice il medico (ho chiesto anche a mia moglie per conferma ) di usarla per forza non vedo perchè non supportarla. Almeno non mi sembra una ragione sufficiente
"il codice è meno efficiente" Questa mi sembra piovuta dal cielo... non saprei proprio su che si basi un'affermazione simile... a occhio direi che esattamente il contrario, semmai.
"Rende problematica la gestione di progetti complessi". May be...

Non uso C++ da una vita ma questa, l'ereditarietà multipla, mi era sempre parsa come uno strumento molto potente e che, se usato cum grano salis poteva anche ridurre i tempi di sviluppo.
Che ne dite?

[Alvaro Vitali]

"troppo complessa e soggetta a bug la programmazione"

La verità credo sia questa, l'ereditarietà multipla, anche se uno strumento molto potente, è causa di grossa complessità e può dar luogo a comportamenti imprevisti a causa, ad esempio, di situazioni ambigue quali l'overriding di un metodo che è presente in entrambe le classi "madri", per quanto risolvibile richiamandolo in modo esplicito con l'operatore di risoluzione dello scope "::" ed il nome della classe.

Concordo con te che non essendo obbligatorio usarla potevano permetterla lasciando al programmatore il "rischio" di usarla.
CIAO!

[anx721]

Lasciare in un linguaggio tutti questi "rischi" significa quasi sempre incorrere negli errori. Tutti i linguaggi moderni sono progettati per fare in modo che li programmatore non incappi negli errori, java soprattutto spinge molto in questa direzione, per cui si tende ad evitare certe funzionalità che spesso complicano di molto la semantica e la sintassi di un linguaggio per apportare benefici minimi oltre a favorire gli errori.

[atragon]

Originariamente inviato da anx721

Lasciare in un linguaggio tutti questi "rischi" significa quasi sempre incorrere negli errori. Tutti i linguaggi moderni sono progettati per fare in modo che li programmatore non incappi negli errori, java soprattutto spinge molto in questa direzione, per cui si tende ad evitare certe funzionalità che spesso complicano di molto la semantica e la sintassi di un linguaggio per apportare benefici minimi oltre a favorire gli errori.

Questo è senz'altro vero, ad esempio anche C# fa suo questo aspetto a livello di specifiche di progettazione. Quello che mi pare è che la modellazione per così dire "realistica" degli oggetti può venire un po' castrata da questa mancanza ed è una limitazione che non approvo, personalmente. Mi pare una lacuna che in alcuni casi costringe a dei giri non proprio ortodossi. Per me, tanto per dirne una, le interfaccie sono un poco elegante trucchetto per non far sentire troppo questa assenza ai programmatori.

[71104]

in ogni modo si risolve molto facilmente, anche se l'eleganza è poca: supponiamo che hai le classi A e B e che vuoi creare C che deriva contemporaneamente da A e B; in C++ ok, lo fai, in Java no; e allora che fai? fai derivare C da A (ad esempio) e includi in C una istanza di B come membro pubblico. poco elegante, ma imho la migliore.
ciao

[fek]

Originariamente inviato da atragon

Questo è senz'altro vero, ad esempio anche C# fa suo questo aspetto a livello di specifiche di progettazione. Quello che mi pare è che la modellazione per così dire "realistica" degli oggetti può venire un po' castrata da questa mancanza ed è una limitazione che non approvo, personalmente. Mi pare una lacuna che in alcuni casi costringe a dei giri non proprio ortodossi. Per me, tanto per dirne una, le interfaccie sono un poco elegante trucchetto per non far sentire troppo questa assenza ai programmatori.

Secondo me la domanda giusta e': mi fai un esempio di caso in cui l'ereditarieta' multipla ti permette di risolvere il problema in maniera piu' semplice rispetto ad altri costrutti? Se mi fai l'esempio, siamo sicuri che non riesci a modellare il problema di modo da non aver bisogno dell'ereditarieta' multipla semplificando la soluzione?

Esistono situazioni in cui il problema non puo' essere risolto in altro modo piu' semplice, ma sono rarissimi e per questi rari casi il C++ va benissimo. Non vedo perche' si debba complicare un linguaggio per portarsi dietro un grado di flessibilita' che va usato solo molto raramente, quindi per me e' giusto che C# e Java non abbiano ereditarieta' multipla.

E le interfacce non sono un modo per nascondere questa mancanza

[fek]

Originariamente inviato da 71104

in ogni modo si risolve molto facilmente, anche se l'eleganza è poca: supponiamo che hai le classi A e B e che vuoi creare C che deriva contemporaneamente da A e B; in C++ ok, lo fai, in Java no; e allora che fai? fai derivare C da A (ad esempio) e includi in C una istanza di B come membro pubblico. poco elegante, ma imho la migliore.
ciao

Oppure ancora piu' semplicemente fai "composition" fra le due classi ed esponi le due interfacce nella classe C che contiene la classe A e la classe B.

Se esporre le due interfacce porta la classe C ad avere un'interfaccia troppo complessa allora questo e' un ottimo segnale che il design e' troppo complesso e la soluzione non e' l'ereditarieta' multipla, ma e' semplificare il design e dividere la classe C secondo il principio: "Ad ogni elemento una e una sola responsabilita'".

[atragon]

Originariamente inviato da fek

Secondo me la domanda giusta e': mi fai un esempio di caso in cui l'ereditarieta' multipla ti permette di risolvere il problema in maniera piu' semplice rispetto ad altri costrutti? Se mi fai l'esempio, siamo sicuri che non riesci a modellare il problema di modo da non aver bisogno dell'ereditarieta' multipla semplificando la soluzione?

Esistono situazioni in cui il problema non puo' essere risolto in altro modo piu' semplice, ma sono rarissimi e per questi rari casi il C++ va benissimo. Non vedo perche' si debba complicare un linguaggio per portarsi dietro un grado di flessibilita' che va usato solo molto raramente, quindi per me e' giusto che C# e Java non abbiano ereditarieta' multipla.

E le interfacce non sono un modo per nascondere questa mancanza

Più o meno è il pensiero corrente e cioè che il gioco non valga la candela.... nonostante, mi pare di poter dire, l'ereditarietà multipla sia il sistema più "totale", non mi viene in mente un altro termine ora, non è in realtà mai l'unico modo per risolvere i problemi.
Cmq sto anche leggendo questo:
http://weblogs.asp.net/fbouma/archiv.../04/47476.aspx
mi pare interessante....