Infatti nessuno mai andrebbe a scrivere un'istruzione come quella che ho scritto io nel mio primo esempio... istruzioni di quel tipo (lecite, sia chiaro!) le trovi solo nei libri didattici, nei manuali, nei tutorial, ecc... sono esempi "accademici" per far comprendere il concetto. Nessuno, nella pratica, li usa mai...

Quello che succede, invece, è proprio l'esempio citato da andbin: un metodo che riceve un generico oggetto di una superclasse X (o di una interfaccia Y!) perchè a lui non interessa il tipo specifico, ma solo la funzione "generica" comune a tutti i tipi.

Facciamo un esempio un po' più concreto... il metodo add() dei contenitori grafici di Swing. Al metodo add() non interessa se gli viene passato un JButton, una JLabel, un JList, un JPanel o un qualsiasi altro componente... a lui interessa che gli venga passato un generico "JComponent" perchè sa che qualunque cosa essa sia la tratterà sempre allo stesso modo: andrà a metterla in un determinato punto del contenitore e magari ne sfrutterà caratteristriche comuni (come la posizione assoluta, la dimensione, il bordo, ecc). Quel metodo, quindi, riceverà un JComponent che, di volta in volta, sarà un JButton una JLabel, ecc. Quindi tale metodo potrebbe essere:

codice:
public void add(JComponent c) {
   ...
   int height = c.getHeight();
   int width = c.getWidth();
   ...
}
Se io gli passo una JLabel, il metodo lavorerà con altezza e larghezza della mia JLabel... se gli passo un JScrollPane lavorerà con altezza e larghezza del mio JScrollPane... ma se io gli ho passato una JLabel lui non può inventarsi di fare un downcast dell'oggetto "c" a JScrollPane... perchè ciò che io gli ho passato non è un JScrollPane.


Spero di essere riuscito a chiarire almeno in parte l'utilità dell'ereditarietà (ma lo stesso discorso vale, forse ancor più, per il polimorfismo).


Ciao.