Newsgroup: it.comp.java
Titolo: Problema con le extension

Salve,
ma e' possibile che in Java si possa estendere solo una classe ???
non e' possibile fare una cosa tipo
class miaclasse extends Applet, miasecondaclasse
???

...

Non e' possibile, questa' e' una delle differenze fra C e Java. Da quello
che ho capito all'inizio volevano implementare il polimorfismo ma poi
si sono arresi di fronte all'evidenza che questa caratteristica avrebbe
reso il linguaggio meno robusto.
--
Andrea Marchini
The Gate: 
http://thegate.mediacom.it/clientd.html
Java Ready Petition: 
http://www.javalobby.org/servlet/PetitionServlet/pjpc

Peccato ... avrebbe risolto un sacco di problemi ...



No, l'ereditarietà multipla è una delle caratteristiche del C++ che non sono
riportate in Java (mancano anche i template, l'overloading degli
operatori...) per una scelta "filosofica" volta a mantenere il linguaggio
più semplice (in fondo molti programmatori C++ sono soprevvissuti fino a
oggi lavorando con compilatori che supportavano solo parte delle "features"
avanzate di questo linguaggio!).
Una soluzione parziale al problema è offerta dalle interfaces che permettono
di specificare un set di funzioni che vengono supportate da un oggetto,
indipendentemente dalla classe base.
Se il tuo problema è invece più complesso e devi far supportare all'oggetto
x di classe a1 (derivata da a) tutte le funzionalità della classe b, puoi
sempre allocare, all'interno di a1 un oggetto di classe b e renderlo
visibile (meglio se via get/set) all'esterno.
---
Valter Minute
min...@fortech.it
 (the reply address of this message is invalid)
---
Are you looking for a good freeware ScreenSaver? Try FOYD!
http://hotfiles.zdnet.com/cgi-bin/texis/swlib/hotfiles/getit.bin?fcode=000PZ
0
if you want, I can send you the (free) C++ source code.

Peccato ... avrebbe risolto un sacco di problemi ...
L'eredita` multipla di implementazione (che in Java manca, e che
tu dici ti "risolverebbe un sacco di problemi") non aggiunge _quasi_
nessuna funzionalita` rispetto a quello che puoi ottenere con la
delegazione e l'implementazione di interfaccie -- l'unica sostanziale
eccezione e' se devi lavorare, senza modificarli, con DUE o piu`
framework esistenti e mal progettati (anche in questo caso, pero`,
il valore aggiunto sarebbe marginale, grazie all'esistenza delle
inner classes).
In pratica, dove spontaneamente ti verrebbe da scrivere:
    class a extends b {
        //... ecc ...
    }
puoi sempre, e senza alcun costo al di la della piccola scomodita`
di scrivere qualche riga di piu` (ma nessuna difficolta` concettuale)
scrivere (se il design del tutto e` sotto il tuo controllo):
    interface Ib {
        // definizione dei metodi pubblici di b
    }
    class b implements Ib {
        // come la classe b che usi adesso
    }
    // in qualunque punto del codice dove ora usi b, usa invece Ib,
    // eccetto che dove _generi_ oggetti di classe b
    class a implements Ib {
        b mysuper;
        // usa mysuper dovunque prima usavi super
        // reimplementa tutti i metodi di Ib, trivialmente:
        void unmetododiIb(void) {
            mysuper.unmetododiIb();
        }
        int unaltro(int a) {
            return mysuper.unaltro(a);
        }
        // ecc ecc
    }
Il "boilerplate" che cosi` devi scriverti e` meccanico, noioso,
ripetitivo, ma, appunto per tutto questo, semplicissimo.
Le inner classes aiutano a rimuovere una parte di questo
boilerplate in vari casi comuni.
Cosi` come in questo modo rimuovi e sostituisci un extends,
cosi` puoi rimuoverne e sostituirne tanti a tuo piacere, visto
che sul numero di _implements_ di una classe non c'e alcun
vincolo ne` problema.
Secondo me, molto piu` che l'eredita` molteplice di
implementazione con le sue complicazioni, in Java per
snellire e facilitare questo tipo di strategia ci vorrebbe
una keyword a livello classe del tipo "delegate_to"; cosi`
che, nell'esempio di cui sopra, "delegate_to mysuper;"
direbbe al compilatore di generare per noi tutte le banali
implementazioni di metodi dell'interfaccia Ib destinati
altrimenti a restare astratti.  Per fortuna, questo non e'
poi tanto difficile da implementare con un programma ad
hoc di "generatore di codice" (come con tutti i generatori
di codice, il problema e' sempre e solo quello di potere
debuggare e manutenere il codice in termini del sorgente
originale e non di quello generato...).
Alex

 reso il linguaggio meno robusto.
Sei sicuro di non confondere il polimorfismo con l'ereditarieta'
multipla?
-- 
"Despite all my rage I'm still just a rat in a cage"

multipla?
Si, sono sicuro di essermi sbagliato! :D



Il polimorfismo, comunque, può essere più o meno simulato con
l'ausilio delle interfacce... Il perchè non sia stato implementato del
polimorfismo vero sta nell'ambiguità insita nel concetto di
polimorfismo... se le due (o enne...) classi da cui eredito
implementano entrambe un metodo 
public void pippo()
con due implementazioni differenti quale deve essere ereditato? Per
questo motivo il polimorfismo é ambiguo!
Ci RiLeggiamo!!!
Matteo!!!

--
Siamo in due! :P
Matteo!!!