Newsgroup: it.comp.java
Titolo: Dubbio sull'ereditarietà

Ciao a tutti
Premetto che è da un bel pezzo che non scrivo una riga di codice da
prima di prendere in mano il progetto su cui stò lavorando..
Proseguendo con il lavoro mi è sorto il seguente dubbio..
Supponiamo di avere il seguente codice:
public abstract ClasseAstratta {
    protected static Object oggetto;
    public abstract void metodo1();
}
public class ClasseConcreta1 extends ClasseAstratta {
    public void metodo1() { ... }
    // Metodi vari ed eventuali
}
public class ClasseConcreta2 extends ClasseAstratta {
    public void metodo1() { ... }
    // Metodi vari ed eventuali
}
La mia domanda è ClasseConcreta1 e ClasseConcreta2 condividono lo
stesso oggetto statico o questo è diverso da classe a classe?
Se fosse lo stesso dice che converrebbe mettere in shadow un nuovo
oggetto statico per evitare di ottenere la stessa risorsa?
Mi è sorto questo dubbio perchè volevo generalizzare una parte del
programma ma ho la necessità di avere per le sottoclassi un oggetto
condiviso differente....
Ciao a tutti e grazie 1000 in anticipo
Buon ponte
Marco

    protected static Object oggetto;
Sei fuori strada: questo oggetto statico è un oggetto globale condiviso 
da tutta l'applicazione.

 da tutta l'applicazione.
adesso i dubbi li hai fatti venire a me quindi ti chiedo: non ï¿œ sbagliato  
dire
che l'oggetto statico ï¿œ condiviso dall'intera applicazione ?
un oggetto "static protected" ï¿œ "condiviso" dalle classi che estendono la  
classe
che lo definisce, in qualunque package siano definite, finchï¿œ non lo  
ridefiniscono
a loro volta...
ï¿œ invece "accessibile" dalle altre classi dell'applicazione solo se queste  
sono
sue suddette sottoclassi, OPPURE se non lo sono ma sono definite nello  
stesso package...
tutte le altre classi si attaccano allegramente :D
-- 
----------------------------------------------------------------------------------
        /)/)             La mia vita ï¿œ tutta rose e fiori...
       ( '.')
     o(('')('')                          ... ma io sono allergico !!!

 a loro volta...
altolï¿œ :-)
non "finchï¿œ non lo ridefiniscono a loro volta" ma anche dopo. quando si 
parla di oggetti statici non si parla di overloading ma di hiding e gli 
oggetti padre/figlio continuando ad essere referenziabili entrambi.

 oggetti padre/figlio continuando ad essere referenziabili entrambi.
sono "visibili" entrambi solo da chi sta ridefinendo... ulteriori
sottoclassi di chi ha ridefinito "vedranno" solo l'oggetto ridefinito;
potranno sempre accedere a quello "originale" ovviamente ma non usandone
solo il nome, ma col riferimento esplicito alla classe originale...
sbaglio ?



Ok allora mi ricordavo bene. vedrò di aggirare il problema in qualche
modo.

 tutte le altre classi si attaccano allegramente :D
Stai confondendo, quello che dici e' valido per effetto del modificatore 
protected, che definisce lo "scope" di una variabile. Il modificatore 
static non ha nulla a che fare con lo scope, dice solo che la variabile 
static verra' inizializzata una sola volta nell'applicazione, 
indipendentemente da chi lo vede, ed ovviamente dipendentemente dal suo 
scope.
-- 
Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherA�ejoAlcoolInside
Spaccamaroni andate a cagare/Spammers not welcome/Spammers v�o � merda
Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'

 scope.
lui ha usato entrambi i modificatori infatti, specificando protected,
non ï¿œ quindi vero che quell'oggetto statico sia visibile da tutto
il resto dell'applicazione


 il resto dell'applicazione
Siamo pignoli, eh? :-)
E' "statico" per tutta la durata dell'applicazione.
E' visibile dalle sole classi che estendono la classe che dichiara 
"oggetto".


 
Siamo pignoli, eh? :-)
E' statico, quindi, dopo l'inizializzazione, ha lo stesso valore per 
tutta la durata dell'aplicazione.
E' protected, quindi visibile da tutte le classi che estendono la classe 
che lo dichiara.
Ma se nella classe ci fosse un metodo statico:
public static Object getOggetto() {
   return oggetto;
}
oggetto sarebbe anche visibile da tutta l'applicazione da qualsiasi 
classe ed accessibile in modo statico.


 classe ed accessibile in modo statico.
non ï¿œ questione di essere pignoli, ma precisi: non ï¿œ che uno puï¿œ
prendersela con il compilatore pignolo se scrive "static protected"  
credendo
di rendere l'oggetto visibile a tutta l'applicazione, ma quello
gli segnala l'errore...
non ï¿œ colpa mia se i computer fanno quello che gli dici di fare, e non
quello che vuoi che facciano ;)


 "oggetto"...
...e a tutte le classi dello stesso package della classe che dichiare 
"oggetto", anche se non la estendono.

 "oggetto", anche se non la estendono.
adesso perï¿œ ti becchi anche tu del "pignolo", sennï¿œ
dove sta la par condicio ? ;)
MAGARI l'informatica fosse solo questione di pignoleria,
sarebbe tutto piï¿œ facile... che odio quando i software
sono progettati bene poi sono i runtime-environments, o
i sistemi operativi, o i frameworks, o quello che vi pare,
a dare di matto e incasinarti la vita


il 04/05/2009 19.54, Scrive Marco 43691976:

Il modificatore "protected" limita la visibilita' alle sole classi che 
estendono la classe dichiarante. La visibilita' al package la si ottiene 
con lo scope di default, ovvero se non e' specificato.


 quello che vuoi che facciano ;)
C'e' um malinteso, non volevoo mica essere offensivo. L'OP poneva 
l'accento sul modificatore "static" esemplificando con classi che 
estendevano tutte la stessa classe, per cui, attinendosi strettamente 
alla domanda posta, il modificatore "protected" era ininfluente.


 con lo scope di default, ovvero se non e' specificato.
eh no, ï¿œ un errore: il modificatore di default, ovvero "package-private",
rende visibile l'oggetto solo all'interno del package di definizione...
il modificatore "protected" rende l'oggetto visibile in tutto il suo
package di definizione ed in ogni sottoclasse, ovunque definita...
dal java tutorial:
- "If a class has no modifier (the default, also known as package-private),
   it is visible only within its own package";
- The protected modifier specifies that the member can only be accessed
   within its own package (as with package-private) and, in addition,
   by a subclass of its class in another package.


 classe ed accessibile in modo statico.
veramente "static" indica che l'oggetto � unico e condiviso tra le 
istanze della stessa classe, il valore che assume pu� cambiare, non � 
"final".
sv.

il 05/05/2009 13.50, Scrive sv 43546984:

Ovviamente, intendevo "dopo l'inizializzazione e se nessuno lo cambia".
Mi compiaccio: questo e' un n.g. di "precisi"!
:-))


 
No, non volevo fare il pignolo... ï¿œ solo che questa cosa non ï¿œ sempre 
chiarita a dovere dove si spiega il significato di "protected" (io l'ho 
scoperto per caso tempo fa, dopo aver notato che un metodo dichiarato 
"per errore" protected anzichï¿œ public veniva utilizzato da un'altra 
classe, del tutto indipendente, nello stesso package, senza che il 
compilatore si fosse mai lamentato della cosa).

 compilatore si fosse mai lamentato della cosa).
eh, lo trovo anche io un sistema piuttosto bislacco...
chissï¿œ se Java includerï¿œ in futuro qualcosa di simile ai modificatori
"internal" e "internal protected" di C#, dove "protected" concede  
visibilitï¿œ
solo alle sottoclassi, mentre "internal" la concede a tutte le classi
incluse nello stesso assembly, dividendo cosï¿œ i due casi


 incluse nello stesso assembly, dividendo cosï¿œ i due casi
Secondo 
http://www.lattecafe.net/java/articoli/javakeyword2.htm
 "Accanto 
al modificatore protected esiste anche il modificatore private protected 
che consente l'accesso solo alle sottoclassi.". Ma una volta che ci ho 
provato, il compilatore mi ha risposto a parolacce...

 provato, il compilatore mi ha risposto a parolacce...
Ho appena trovato questo sull'argomento:
http://forums.sun.com/thread.jspa?threadID=205562&tstart=12000
[CUT]
In the first version of java there was the additional modifier "private 
protected" which did what you suggests.
It was dropped because it seemed to provide more confusion than benefit.
[CUT]

 provato, il compilatore mi ha risposto a parolacce...
credo sia una di quelle cose che ti serviranno un paio di volte nella vita,
ma che se non ci sono ti costringono a dei salti mortali nel codice...
