[JAVA] un dubbio o mistero da sfatare

[misterx]

mi sa che ci vorrebbe un bell'esempio

tu hai provato ad implementarne qualcuna ?

[PGI]

L'uso di una delle interfacce esistenti nelle librerie Java è praticamente inevitabile (basta pensare ad ActionListener nelle applicazioni grafiche). Anche in applicazione a consolle è piuttosto facile imbattersi in una delle interfacce esistenti (a meno di non limitarsi a scrivere "Hello world" e altre amenità).

Con le interfacce puoi generare strutture gerarchiche piuttosto articolate. L'esempio che segue è un caso di "polimorfismo estremo": un oggetto che "è" di 4 tipi diversi (usando le sole interfacce, con l'ereditarietà di classe la cosa può complicarsi anche di più).

La prima interfaccia definisce due costanti e un metodo astratto. Tutti i campi di un interfaccia sono per definizione "public static final".

public interface Nominabile {
	String NOMINABILE="ha un nome";
	String INNOMINABILE="ha un nome ma non puo' dirlo";
	
	public String getNominabile();
}

Seconda interfaccia, altre due costanti ed un metodo:

public interface Tipo {
	String TIPO_1="oggetto di tipo 1";
	String TIPO_2="oggetto di tipo 2";
	
	public String getTipo();
}

Terza interfaccia, figlia di Nominabile e di Tipo (ereditarietà multipla, supportata solo dalle interfacce):

public interface TipoNominabile extends Tipo, Nominabile {
	public String getCombinazione();
}

Oggetto che implementa l'interfaccia "TipoNominabile":

public class UnOggetto implements TipoNominabile {
	public String getTipo() {
		return TIPO_1;
	}
	
	public String getNominabile() {
		return INNOMINABILE;	
	}	
	
	public String getCombinazione() {
		return TIPO_1+" "+INNOMINABILE;
	}
	
	public String toString() {
		return "un oggetto";	
	}
		
}

Codice che mostra come l'ereditarietà multipla interagisce con il polimorfismo dei riferimenti:

class Application {

	Application() {
		UnOggetto o=new UnOggetto();
		stampaUnOggetto(o);
		stampaNominabile(o);
		stampaTipo(o);
		stampaTipoNominabile(o);		
	}
	
	public void stampaNominabile(Nominabile n) {
		System.out.println(n.getNominabile());	
	}
	
	public void stampaTipo(Tipo t) {
		System.out.println(t.getTipo());	
	}
	
	public void stampaTipoNominabile(TipoNominabile tn) {
		System.out.println(tn.getCombinazione());	
	}
	
	public void stampaUnOggetto(UnOggetto o) {
		System.out.println(o);	
	}
		

	public static void main(String[] args) {
		new Application();
	}
}

A titolo di curiosità, quando passi ad un metodo un riferimento di tipo interfaccia in realtà non passi un'istanza dell'interfaccia ma di un oggetto che implementa l'interfaccia.
Una cosa simile capita quando in un metodo definisci una variabile di tipo interfaccia:
...corpo di un metodo
Interfaccia interf=new Interfaccia() {
//implementazione dei metodi astratti...
}
metodo(interf);

Per farla breve, "new Interfaccia()" è una scorciatoia: in esecuzione quello che accade è che la jvm crea un oggetto che implementa l'interfaccia usando la definizione dei metodi che hai fornito nella classe astratta.

[misterx]

scusa ma entro un attimo nell'argomento delle classi astratte in quanto se non ho capito male, le interfacce altro non sono che surrogati di classi astratte

abbiamo

A _________
|          |
B         C

A=superclasse
B e C = sottoclassi che condividono qualcosa con A ma non tra loro

come mai nella superclasse A devono comparire, sotto forma di dichiarazioni abstract, i metodi implementati in B e C ?

forse sono una sorta di segnalatore che evitano alla JVM di cercare in A ciò che non troverebbero e dicono sempre alla JVM di cercare direttamente attraverso il riferimento comune nella classe istanziata alla quale punta il riferimento ?

spero di essere stato chiaro

[PGI]

La risposta potrebbe essere "ni" ad entrambe le questioni.

Per certi aspetti è vero che le interfacce sono versioni "minori" delle classi astratte (perchè una classe astratta può avere metodi con un corpo mentre un'interfaccia no)

Per la seconda domanda, non è del tutto esatto dire che una superclasse debba avere dei metodi astratti: l'uso del modificatore abstract ha uno scopo ulteriore rispetto alla semplice ereditarietà ed in particolare costringe ogni sottoclasse che non sia a sua volta "abstract" ad avere una propria definizione del corpo del metodo.

Hai però toccato (volontariamente o meno ) un argomento su cui ho qualche perplessità (e che stò approfondendo) e che riguarda indirettamente il supporto Java al binding statico e dinamico: personalmente credo che Java supporti entrambe i tipi di "collegamento" ma, come si usa dire, al momento non ne ho la prova...tra qualche centinaia di pagine web ti saprò dire con più precisione.

Mi "riservo" spiegazioni ulteriori in futuro

[misterx]

io di dubbi ne ho anche di più, più proseguo e più ne colleziono

stavo leggendo QUI

dove è presente la costruzione step by step di alcune classi astratte/concrete

peccato che l'autore non dice cosa accadrebbe se le superclassi non le dichiara abstract

posso lavorare con le soli classi concrete allo stesso modo di quelle astratte ?

se lavoro con tutte classi concrete perdo l'ereditarietà ?

[PGI]

Dal punto di vista dell'ereditarietà non c'è differenza tra classi astratte e non astratte.

Quello che cambia è che non si può creare un nuovo oggetto a partire da un modello di classe astratta.

es.

abstract class ClasseAstratta{...}

ClasseAstratta a=new ClasseAstratta() <- errore (in compilazione)

Il motivo dipende da come la jvm inizializza gli oggetti: l'operatore "new" comporta la "creazione" di tutti i metodi e campi dichiarati in una classe. Poichè le classi astratte hanno alcuni metodi senza corpo l'operazione non è ammessa.

In pratica puoi sicuramente lavorare con classi "normali" come faresti con classi astratte, ma non puoi usare le classi astratte come faresti con quelle normali.

E allora che cavolo se ne fa uno delle classi astratte?
Una classe astratta può essere necessaria quando nella fase di progettazione scopri che avrai bisogno di un riferimento polimorfico "esclusivamente dinamico". Noterai che di solito gli esempi che trovi sull'argomento sono piuttosto simili:

superclasse astratta che indica un genere (veicolo, animale o mammifero ecc... la fantasia abbonda ) e sottoclassi che definiscono un tipo del genere (auto, moto, cane gatto ecc...).

la classe che indica il genere è usata proprio per esemplificare la necessità (o l'utilità) di un riferimento "generico" che può assumere in concreto svariate forme (una per tipo).

[misterx]

Originariamente inviato da PGI

Una classe astratta può essere necessaria quando nella fase di progettazione scopri che avrai bisogno di un riferimento polimorfico "esclusivamente dinamico".

cioè se la classe non è astratta non può esistere il polimorfismo ?

[PGI]

Originariamente inviato da misterx
cioè se la classe non è astratta non può esistere il polimorfismo ?

Nain! Il polimorfismo in sè dipende dall'ereditarietà (che coinvolge le classi in genere, astratte o meno).

Facciamo un esempio:

abstrac class ClassA {
abstract void doSome();
}

class Child extends ClassA {
void doSome{
System.out.println("Ciao");
}
}

riferimento polimorfico:

ClassA pointer;
Child child=new Child();
pointer=child;
pointer.doSome() <- questo doSome() non è mai quello della classe-tipo usata per il puntatore, il suo contenuto dipende sempre dalla classe a cui appartiene l'oggetto puntato.

Con classi "comuni":

class Parent {
public void doSome() {
System.out.println("Ciao");
}
}

class Child extends Parent {
}

Parent pointer;
Child child=new Child();
pointer=child;
pointer.doSome(); <- questo metodo è quello del tipo usato per il puntatore (cioè la classe genitore) a meno che la sotto-classe non lo ridefinisca.

[misterx]

stai diventato sempre più complicato

ascolta, propongo di tenerci il codice sotto per ragionare sulle classi astratte, concrete ed interfacce: che ne dici ?

nel frattempo mi manda in output null

class Negoziante {
 public String insegna;
 public String getInsegna() {
  return insegna;
 }
}

class Pizzeria extends Negoziante {
 public String Pizzeria() {  
 	return "Pizzeria";
 }
}

class Ristorante extends Negoziante {
 public String Ristorante() {
 	return "Ristorante";
 }
}

:D:D:D

class Pgi { 

public static void main (String[] args) {

    Negoziante n = new Pizzeria();
   
    System.out.println(n.getInsegna());
    
System.out.println("ciao");

}
}

[PGI]

Di che ti taglierei le dita

Negoziante n=new Pizzeria(): ok

System.out.println(n.getInsegna()): ok, ma qual'è il metodo "getInsegna()" che viene chiamato?

Poichè la sottoclasse Pizzeria non sovrascrive quello della superclasse è il metodo "getInsegna()" di Negoziante.

E va benissimo. Ora dobbiamo guardare quello che fa il metodo "getInsegna()" di Negoziante: restituisce la stringa "insegna".

Passiamo allora al campo "insegna" di Negoziante: è ereditato da Pizzeria? Si. Pizzeria definisce un valore per "insegna" (cioè pizzeria sovrascrive il campo o richiama un metodo che influenza il valore del campo) ? No.

Allora che valore ha "insegna" nell'oggetto di tipo Pizzeria? Ha il valore "originale", definito dalla superclasse Negoziante.

E il suo valore è null (insegna è un campo non inizializzato, in java punta automaticamente a "null" se è un oggetto) -> risolto il mistero.

Prima di passare a classi astratte e interfacce è meglio maneggiare un po' le classi "normali" (sbagliando si impara moltissimo, ma è meglio sbagliare una cosa alla volta).

class Pizzeria extends Negoziante {
 public String Pizzeria() {  
 	return "Pizzeria";
 }
}

Cosa c'è che non va qui: in questo caso "Pizzeria()" non è il costruttore della classe. A scanso di equivoci, un costruttore non è un metodo con lo stesso nome della classe ma è un metodo che oltre ad avere lo stesso nome della classe non ha un tipo restituito (nè void nè primitivi nè oggetti). Quindi Pizzeria è una sottoclasse di Negoziante che definisce un metodo "Pizzeria()" che, se chiamato, restituisce una stringa con la parola "Pizzeria".
E ha poco a che vedere con lo scopo delle classi (ereditarietà e polimorfismo).

Il risultato presumibile si ottiene invece dando a Pizzeria un costruttore che sovrascriva il campo "insegna" così:

class Pizzeria extends Negoziante {
 Pizzeria() {
  insegna="Pizzeria";
 }
}

Dovresti provare a fare qualche esercizio sull'ereditarietà creando qualche gerarchia di classi.

Siccome il thread assomiglia sempre di più ad una chat, che a me va benissimo, ma agli amministratori del forum un po' meno (per ottime ragioni tuttavia), ti mando in pvt la mia e-mail .

&Ciao.

[a2000]

misterx quand'è che la smetterai di metterti a culo busone ?

[misterx]

Originariamente inviato da a2000
misterx quand'è che la smetterai di metterti a culo busone ?

uhm, sarai mica amante esclusivo del fai da te e = (super orgoglioso) eh ???

aho, mi faccio solo da me

lasiammo stare va, che entrerei in un argomento un pò troppo spinoso

[a2000]

"uhm" , probabilmente credo nelle tue capacità più di quanto ci creda tu stesso ...

forse sei pigro ...

ti devi solo applicare ...

[misterx]

Originariamente inviato da a2000
"uhm" , probabilmente credo nelle tue capacità più di quanto ci creda tu stesso ...

forse sei pigro ...

ti devi solo applicare ...

pigro non molto, arrugginito parecchio

cmq, è risaputo che è più facile imparare java per chi non conosce alcun linguaggio di programmazione

per chi come me che conosce già un linguaggio imperativo come il C si trova in una posizione leggermente sfavorevole; java è molto astratto, il C lo è molto meno

ma sto rimediando grazie anche alla pazienza degli utenti di questo forum

l'importante è tenere duro

[a2000]

nei post, come nella vita, conta solo l'inizio e la fine:

Originariamente inviato da misterx
pigro non molto, arrugginito parecchio
....
l'importante è tenere duro

vai tranquillo l'uccello non si arrugginisce mai !

[misterx]

Originariamente inviato da a2000
nei post, come nella vita, conta solo l'inizio e la fine:


vai tranquillo l'uccello non si arrugginisce mai !

cmq, so cosa intendi

[a2000]

sono entrambi organi cavernosi !

e con funzioni intercambiabili a seconda dell'oggetto su cui vengono applicati !


POLIMORFISMO = La capacita' di ottenere comportamento specializzato, invocando un servizio generico, attraverso le informazioni sul tipo dell'oggetto al quale si richiede il servizio, che possono essere ottenute staticamente (static-binding), oppure dinamicamente (late-binding).

[a2000]

vedi misterx bisogna avere un approccio funning alla conoscenza:

se la gente ragionasse con l'uccello e scopasse con la testa (non in senso figurato) il mondo probabilmente andrebbe meglio.

se non altro ci sarebbero molti meno calvi in giro !!!!

[a2000]

devo approfondirlo sto' concetto di polimorfismo ...

ma un uso polimorfo (nel senso suddetto) degli oggetti non confligge con l'ereditarietà ????

[misterx]

Originariamente inviato da a2000
devo approfondirlo sto' concetto di polimorfismo ...

ma un uso polimorfo (nel senso suddetto) degli oggetti non confligge con l'ereditarietà ????

ti stai dando la zappa zui piedi ??