Classi astratte ed interfacce utilità

[rick.card82]

Ciao,

il concetto mi è chiarissimo, è che faccio un po fatica a trovarne l'utilità nella pratica, nel senso:
ovviamente non istanzio un Solido astratto, ma istanzio un Cubo che è di per se un solido, cioè, che vantaggio ho nella programmazione pratica derivare da una classe astratta?
Se parliamo di derivare una classe da un'altra che ha già metodi e proprietà utilizzabili ne vedo l'utilità, derivare da una che ha solo definizioni senza "ciccia" dentro non riesco a trovarlo utile o forse mi manca qualche pezzo ;(

[andbin]

ovviamente non istanzio un Solido astratto, ma istanzio un Cubo che è di per se un solido, cioè, che vantaggio ho nella programmazione pratica derivare da una classe astratta?
Se parliamo di derivare una classe da un'altra che ha già metodi e proprietà utilizzabili ne vedo l'utilità, derivare da una che ha solo definizioni senza "ciccia" dentro non riesco a trovarlo utile o forse mi manca qualche pezzo ;(

Innanzitutto una classe marcata abstract può benissimo contenere metodi tutti concreti. Il principio è che se almeno un metodo è abstract, allora la classe DEVE essere marcata abstract. Ma se una classe è abstract non ha di per sé alcun obbligo di avere metodi astratti. Cosa una classe abbia di concreto o no, dipende chiaramente dal senso/livello della classe.

In Solido, a parte il fatto che non ha senso istanziarlo, ci sono due operazioni che Solido da solo non saprebbe cosa farci: calcolare la superficie e il volume. Quindi una classe Solido potrebbe essere:

public abstract class Solido {
    public abstract double calcolaSuperficie();
    public abstract double calcolaVolume();
}

Qui in effetti è tutto astratto. Ma le sottoclassi come Cubo e Sfera, che si presume siano naturalmente "concrete", dovranno per forza di cose implementare questi due metodi. Quindi gli oggetti che istanzierai avranno sicuramente questi metodi implementati.

E comunque con la ereditarietà entra in gioco il polimorfismo e il correlato "principio di sostituibilità": dove è richiesto un tipo X è lecito passare/assegnare un oggetto di tipo X o di un sottotipo di X. Ovunque sia richiesto un tipo Solido, è lecito passare un qualunque sottotipo, es. un oggetto Cubo o Sfera.

Se ci fosse un metodo che riceve un array di oggetti Solido es.

public static double totaleVolume(Solido[] solidi) { .... }

Nota che è assolutamente lecito usare e istanziare un array di un tipo astratto. A quel punto si potrebbe fare:

Solido[] mieiSolidi = new Solido[2];
mieiSolidi[0] = new Cubo( ...... );
mieiSolidi[1] = new Sfera( ...... );

double totVol = totaleVolume(mieiSolidi);

E tutto questo sarebbe assolutamente lecito e sensato. Il metodo totaleVolume "vede" gli oggetti passati solamente come dei Solido. Ma può benissimo invocare il metodo calcolaVolume() sugli oggetti. Il fatto che calcolaVolume sia astratto in Solido NON è un problema. Gli oggetti che passi sono per forza concreti quindi in questi i metodi calcolaSuperficie/calcolaVolume CI SONO, esistono e sono usabili.