Newsgroup: it.comp.java
Titolo: Java e polimorfismo parametrico

  |
|-----------------------------------------|
|       
http://www.pabasoftware.com
       |
+-----------------------------------------+

Oppure sono io che non vedo la soluzione e creo un falso problema?
Momento. Ci sono due casi: o il tipo compiletime e' noto (Base) o non lo e'.
Se non lo e', devi usare instanceof in Java e RTTI in C++, non si scappa. Se lo 
e', l'unica cosa che devi fare in piu' in Java e' un cast al tipo base. Ora, se 
il tipo base e' un interfaccia, ottieni codice cha lavora correttamente su 
tutte le classi che implementano quell'interfaccia. Ci sono ben poche 
situazioni di design in cui questo non e' sufficiente, o porta a effettiva 
minore riusabilita'.
-- 
God is Real, unless declared Integer.
ObjectZone - 
http://space.tin.it/computer/csadun

 minore riusabilita'.
Probabilmente devo cambiare il mio modo di progettare l'applicazione,
ancora legato a caratteristiche che Java non ha.
Oppure forse non ho capito il cast che fa Java!!!!
Se per es. ho le solite Shape e Rect che estende Shape e supponiamo che
entrambe abbiano un loro metoro draw(), e faccio:
Vector v=new Vector();
Rect r=new Rect()
v.add(r);
eccetera
...
poi recupero un elemento da v. Per farlo devo per forza fare un cast a
Shape, perche' io a priori potrei aver messo nel vettore sia oggetti di
tipo Shape che Rect che di altre classi derivate. Dunque devo fare:
Shape s=(Shape)v.elementAt(i); perche' io non conosco il tipo runtime.
A questo punto se chiamo
s.draw();
le mie conoscenze di OOP mi fanno pensare che ho chiamato la draw di
Shape, anche se l'oggetto era un Rect. Giusto?
Allora potrei fare cosi':
1) scopro prima il tipo runtime con un instanceOf
2) con una serie di if differenzio il cast a seconda del tipo
Beh, questo vuol dire che se estendo il programma con nuove classi devo
andare a modificare anche questo pezzo di codice magari residente in
tutt'altra classe... addio estendibilita'!
Questo e' vero ogni volta che faccio un instanceOf, ed e' per questo che
sui libri di OOP si dice che i controlli di tipo non andrebbero mai
fatti.
In sostanza, se mi confermi che non sbaglio qualcosa, resto della mia
idea, ma ammetto che devo approfondire la storia del tipo base
interfaccia e che probabilmente ci sono metodi di design che io non
riesco a pensare perche' probabilmente sono influenzato dalle
caratteristiche del C++ e anche semplicemente perche' non sono
abbastanza colto in materia...






abbastanza colto in materia...
Se l'idea e' che Java favorisce downcast rispetto a C++ con template, e' vero.
Per la riusabilita', non c'e' una grossa differenza. Come dimostrazione 
empirica, dai un'occhiata alla riusabilita' *reale* di librerie Java ben 
scritte (come ad esempio - mediamente - quella standard) rispetto a librerie 
C++ equivalenti. Quando va bene, non c'e' granche' differenza. Quando va male, 
quelle C++ impallidiscono di frontea librerie Java che offrono un'incredibile 
flessibilita' anche su funzionalita' parecchio complesse. Ma non - intediamoci 
- perche' Java sia migliore o che: semplicemente, le buone librerie (Java o 
C++) applicano sempre pattern adatti; e *questo* fa la differenza, molto piu' 
di tecnicalismi di linguaggio.


Non posso che ringraziarti per questa lunga chiacchierata che mi ha
chiarito alcuni punti non del tutto ovvi (per me).
Tutto era partito da un mio errore: io credevo che un cast esplicito
alla classe base in Java cambiasse anche il tipo runtime! (se ci pensi
non e' poi cosi' stupido: se io faccio un cast esplicito io *voglio* che
l'oggetto diventi veramente di quel tipo...)
Beh, grazie della pazienza!
