Newsgroup: it.comp.java
Titolo: Aiuto su eredità.

Ho le seguenti due classi:
class Parent  {
  int f = 1;
  int m() { return 2; }
  static int s() { return 3; }
  int g() { f=4; return s(); }
}
class Heir extends Parent {
  int f = 5;
  int m() { f=6; return 7; }
  static int s() { return 8; }
}
public class Test {
public static void main{String argv[]) {
     Parent p = new Heir();
     System.out.println(p.g());
}
Non riesco a capire bene il meccanismo  per cui mi ottengo in uscita il
valore intero 3.
Se qualcuno ha la pazienza di spiegarmelo mi farebbe un grande piacere visto
che devo preparare l'esame di LP II !!!
Grazie a tutti.
Marcella

Prestituisce tre perchè s è un metodo statico quindi di classe e la
variabile g contine si una istanza di heir ma è di tipo parent e nel momento
in cui si fa accesso al metodo static lui richiama quello di parent.
--------------------------------
Inviato via 
http://usenet.libero.it

 valore intero 3.
Main crea uno spazio in memoria di dimensione P con dentro un oggetto HEIR,
suo "parente".
Stampa il valore restituito dal metodo g() di HEIR. Dato che HEIR non ha un
metodo g(), lo eredita da Parent.
Parent pone il valore di f a 4, e restituisce IL SUO valore di s.
Per ottenere in uscita 8, come pensavi, il metodo PADRE dovrebbe richiamare
il metodo s() di FIGLIO.
Io ragiono cosě, ma dato che non sono un guru di queste cose, avrň
sicuramente detto castronate :)
Byez
J

 valore intero 3
Un metodo statico M invocato da un contesto nonstatico C e' sempre invocato 
rispetto alla classe (tipo statico) che definisce C.
g() e' un metodo di Parent (ed e' un contesto nonstatico), quindi tutte le 
invocazioni statiche all'interno di g() saranno risolte rispetto alla 
classe che lo definisce (appunto, Parent).
Quando invochi g() su p, la catena di override risolve il metodo a livello 
di Parent, quindi il g() chiamato e' quello di Parent.
Se fai l'override di g() in Heir, e al suo interno richiami s(), allora 
l's() invocato sara' quello di Heir.
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun

 ha scritto nel messaggio
news:Xns9284ADFC8386Ecr...@130.133.1.4...


 un overrides di un metodo C implementanto in modo private in A.
Nessuno, e infatti non si puo' fare: se B deriva da A, un metodo privato 
m() di A non e' visibile in B, e non e' richiamabile se si ha un reference 
a B:
B b = new B();
b.m()
genera un errore di compilazione, perche' il tipo statico B _non_ ha a 
tutti gli effetti un metodo m() (se non quando e' valutato nel corpo di un 
metodo di B stesso).
Certamente, puoi aggiungere un metodo privato o pubblico m() anche a B, ma 
tecnicamente non e' un override.


 tecnicamente non e' un override.
Grazie per l'aiuto.

 ha scritto nel messaggio
news:Xns928EA95C07A86cr...@130.133.1.4...


dell'oggetto"
Magari non ti servirà a niente, ma te ne aggiungo una:
L'interfaccia è un contratto.
:-)
-- 
Ciao
	Fabrizio C.

 Grazie ancora.
In breve.
L'interfaccia di una classe specifica un "contratto" 
(di fatto costituito dall'insieme dei suoi metodi pubblici), 
i quali dichiarano i servizi messi a disposizione degli utilizzatori di
quella classe (o sarebbe meglio dire, degli utilizzatori delle istanze 
di quella classe).
Quando dico dichiarare, intendo la specifica di servizi in modo
indipendente dalla loro reale implementazione.
Questo di per se' non sarebbe ancora sufficiente come definizione, 
in quanto occorrerebbe completare il discorso introducendo qualche 
formalismo aggiuntivo che permetta di esprimere in modo non ambiguo 
che cosa si intende effettivamente per "contratto". 
A questo proposito, ti consiglio questo articolo introduttivo sul
"Design by Contract":
http://archive.eiffel.com/doc/manuals/technology/contract/page.html
 
Quanto detto fin qui vale in generale, indipendentemente dal linguaggio
ad oggetti che si utilizza.
In java, il concetto di interfaccia e' stato introdotto nel 
linguaggio in modo esplicito, anche se in modo incompleto 
(vedi paper). E' cosi' possibile costruire una interfaccia 
come un insieme di dichiarazioni di signature di metodi 
(pubblici!) in modo indipendente dalla loro effettiva 
implementazione.
Di fatto, all'interfaccia non interessa nulla di come verranno
implementati i suoi metodi: si tratta di un costrutto 
esclusivamente dichiarativo (vabbe', non e' proprio cosi' perche'
si possono definire anche delle costanti, ma e' un dettaglio...)
Es. di interfaccia in Java:
public interface I
{
  public void unMetodo(...);
  public Object unAltroMetodo(...);
}
Ogni classe che decide di fornire i servizi dichiarati in una specifica
interfaccia, la puo' implementare, con cio' intendendo la definizione
(e quindi la relativa implementazione) di tutti i metodi pubblici 
dichiarati dall'interfaccia stessa.
Es. di classi che implementano l'interfaccia I:
public ClasseA implements I
{
  public void unMetodo(...)
  {
     // fa qualcosa specifico per A
  }
  public Object unAltroMetodo(...)
  {
     // fa qualcos'altro specifico per A
  }
}
public ClasseB implements I
{
  public void unMetodo(...)
  {
     // fa qualcosa specifico per B
  }
  public Object unAltroMetodo(...)
  {
     // fa qualcos'altro specifico per B
  }
}
Come si puo' vedere dall'esempio, data una interfaccia possono 
esisterne tante implementazioni differenti, ma tutte basate 
sullo stesso insieme di metodi pubblici (cioe' quelli dichiarati 
nell'interfaccia stessa).
Classi diverse possono essere "viste" come lo stesso TIPO in virtu' 
del fatto che implementano la stessa interfaccia e cio' permette 
di sfruttare il polimorfismo anche in assenza di ereditarieta'.
Es.
public ClasseC
{
   public void lavora_su_I(I i)
   {
       i.unMetodo(...);
       i.unAltroMetodo(...);   
   }
   public static void main(String[] args)
   {
       classeC c = new ClasseC();
       classeA a = new classeA();
       classeB b = new classeB();
       c.lavora_su_i(a);
       c.lavora_su_i(b);
   }
}
Come si vede, il metodo lavora_su_I() opera su istanze di tipo I, 
cioe' su una qualsiasi istanza di una classe che implementa
l'interfaccia I. Nel metodo main() vengono create istanze di ClasseA
e di ClasseB: siccome entrambe le classi implementano l'interfaccia I, 
le loro istanze SONO di tipo I, quindi possono essere passate al 
metodo lavora_su_I(), il quale ne invoca i metodi secondo la signature 
dichiarata nell'interfaccia, ma a tempo di esecuzione il polimorfismo 
esegue l'implementazione definita in ClasseA oppure in ClasseB, 
a seconda dell'effettiva istanza passata.
Avevo detto che sarei stato breve.
Non ci sono riuscito, ma spero di avere risposto alla tua domanda
in modo sufficientemente esauriente.
Buon lavoro
Roberto
-- 
+----------------------------------+
| Roberto Bagnoli                  |
| Sistemi Informativi e Telematici |
| Comune di Modena                 |
| 
robe...@comune.modena.it
        |
+----------------------------------+

 dare una definizione di interfaccia di una classe?
La confusione nasce dal fatto che "interfaccia" e' tradizionalmente usato 
in OO per indicare il set di membri esposti da una classe (quindi attributi 
e metodi pubblici); mentre in Java indica un costrutto specifico (un set di 
dichiarazioni di metodi e/o membri statici che deve essere implementato 
esplicitamente da una classe).
Quindi se stai parlando in un contesto, per esempio, C++, "interfaccia" 
tende ad avere il primo senso; in Java, a meno di non specificare 
altrimenti, o di un contesto evidente, "interfaccia" io la uso e interpreto 
in senso tecnico.


 ha scritto nel messaggio
news:Xns92926D541CCDCcr...@130.133.1.4...


 metodi senza implementazione" è da sconfessare?
Si'. Cose "private" per definizione non fanno parte dell'interfaccia, in 
nessuno dei sensi possibili.


 implementazione" è da sconfessare?
Direi proprio di si'. L'interfaccia di una classe e' costituita solo dai
suoi servizi pubblici
