Newsgroup: it.comp.java
Titolo: attributi astratti

Qualcuno mi sa dire un buon motivo per cui non esistono attributi astratti, 
ma solo metodi?

 ha scritto nel messaggio
news:Xns918EECB36B...@212.13.1.7...


 ma solo metodi?
Perchè non ha molto senso, forse quello che vorresti tu sono degli attributi 
dichiarati final ma  non inizializzati, ripeto, forse.
Il concetto di abstract serve per specificare delle funzionalità 
nell'interfaccia che però al livello gerarchico di quella interfaccia non si 
può o non conviene dare una implementazione esplicita, quindi capisci bene che 
non ha senso avere attributi astratti.
ciao
Marco
-- 
      \\  |  //
       ( @ @ )
----oOO--(_)--OOo----------[Marco Azzalini]--------------------
Sviluppo Software & Networking - 
marco.a...@libero.it
 
Legge di Hofstadter: 
         ci vuole sempre piu' tempo di quanto si pensi, 
         anche tenendo conto della Legge di Hofstadter.

 ma solo metodi?
Descrivi a parole tue cosa dovrebbe essere un attributo astratto.


|
| Bruno Bossola
| A Java Software Engineer :-)
| 
http://bbruno.fasturl.it
|
| 
http://members.xoom.it/bbruno
| 
http://digilander.iol.it/bbossola
|

 
In pratica, io ho una classe A, contenente questo fantomatico attributo 
astratto non inizializzato, magari utilizzato in lettura nel costruttore 
stesso della classe.
Poi creo una classe B, che eredita da A, e ridefinisce ad un valore 
specifico l'attributo in questione, di modo che il costruttore di A al 
momento di leggere l'attributo legga il valore impostato in B.
Spero di essermi spiegato...

 Spero di essermi spiegato...
Non capisco quello che vuoi dire.
Se A _non_ è una classe astratta, e quindi a senso costruirne un
oggetto, come può il costruttore accedere ad un membro astratto,
quindi non ancora implementato (anche se esistessero le variabili
astratte)?
Al limite puoi fare in modo che la classe _non_ astratta A nel
costruttore richiami un metodo _non_ astratto che eventualmente
ridefinirai in B.
Sia con B  b = new B(); che con A ab = new B(); nel costruttore verrà
usato il valore restituito dal metodo ridefinito in B. Ma con new A()
come è possibile che ciò avvenga?
In ogni caso è in genere inopportuno che un costruttore di una classe
invochi metodi che possano essere ridefiniti, in quanto
l'implementazione di sottoclassi può influire nella costruzione di
oggetti della superclasse.
tityrus

Mi sa di affermazione sibillina. Cosa significa? 



Significa che in Object Oriented (OO) lo stato di un oggetto (in questo caso l'attributo
di cui si sta parlando) non deve essere accessibile se non mediante appositi metodi (i
metodi implementano il meccanismo di scambio dei messaggi in Java). Se non e' cosi, non
stai facendo OO, perche' ne violi la maggior parte dei principi :-D
Ciao,
    Bruno.


> Se A _non_ è una classe astratta, e quindi a senso costruirne un
HA senso.... 
ops...

 quanto non esiste ancora.
Ma se A è astratta non ha senso "costruirne" istanze, e non ti compila.
tityrus

> A è astratta.

io non ne istanzo, ci mancherebbe... 
Ma il suo costruttore è invocato giusto prima del costruttore di B.

 Ma il suo costruttore è invocato giusto prima del costruttore di B.
Quindi, come dicevo in una mail precedente, con B  b = new B() e con A
ab = new B(), insomma costruendo un oggetto di tipo B, verrà
richiamato il metodo eventualmente ridefinito in B. Il costruttore di
A richiamerà il metodo ridefinito in B, e potrà valorizzare i suoi
attributi utilizzando B.
Per capirci, il main stamperà 222:
class AA {
    int astratto;
    AA() {
        astratto = getValore();
    }
    int getValore() {
        return 111;
    }
}
class BB extends AA {
    BB() {
    }
    int getValore() {
        return 222;
    }
}
class Astratto {
    public static void main(String[] args) {
        BB b = new BB();
        System.out.println(b.astratto);
    }
}
tityrus

 
L'idea di costruttore, l'evitare ridondanze e la logica della relazione
base/derivata. 
Vediamo un po': un attributo "astratto" sarebbe, se capisco bene, un
attributo che la classe base impone ci debba essere nella classe
derivata, ma il cui valore sia definito dalla classe derivata. 
Al di fuori della classe, e quindi anche nella relazione base-derivata,
la divisione tra "attributi" e "metodi" e' di comodo: una classe espone
semplicemente features. 
Ma all'interno di una classe (dove c'e' in effetti divisione tra stato -
attributi - e transizioni - metodi), l'approccio OO prevede che lo stato
di una classe (corretta) sia sempre (considerabile come) corretto, da cui
segue che lo stato iniziale debba essere definito nel costruttore.. ed il
costruttore e' il posto dove si deve guardare per vedere quali *valori*
servono per costruire un oggetto di una classe. 
Ora, un attributo astratto implicherebbe solo che il compilatore possa
verificare che il costruttore della classe derivata l'abbia
effettivamente definito - e generi un errore altrimenti... ma cio' e'
perfettamente equivalente a richiedere che quell'attributo sia uno dei
parametri di costruzione: 
abstract class Base { abstract int a; } 
class Derivata { int a = 1; }
equivale sempre a 
abstract class Base { int a; Base(int a) { this.a=a; } }
class Derivata { Derivata() { super(1); } }
che e' piu' in linea con l'idea di costruttore - dato che per un
attributo, cio' che viene definito e' un *valore* - e quindi il posto
giusto per definirlo e' il costruttore della classe derivata. 
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun