Newsgroup: it.comp.java
Titolo: Non ho capito il doppio costruttore

Scusate se posto un'ovvieta', ma non mi e' ben chiaro per quale motivo
si scriva:
public class VeicoloAMotore {
    boolean funzionante;
    String modello;
    VeicoloAMotore(String modello){      
    funzionante=true;
    this.modello=modello;
    }    
}
Ossia, a che serve replicare il costruttore VeicoloAMotore(), con lo
stesso nome della classe, per poi avere anche la replica del parametro
this.modello?
Qual e' la differenza pratica col definire le variabili funzionante e
modello senza ridefinire il costruttore?
Grazie,
Alessio
____________________________
Per rispondermi togli NOSPAM

Alessio O. ha scritto:

MMmm la tua domanda NON e' chiara.
Come sarebbe a dire "replicare" il costruttore?
Io di costruttore ne vedo SOLO UNO nella tua classe.
Se ti riferisci al costruttore di default
VeicoloAMotore() {}
ti ricordo che il costruttore di default ti viene "regalato" dal
compilatore SOLO SE NON NE SCRIVI UNO TUO. Se lo rivuoi te lo devi
scrivere a mano.
Avendo questo:
 public class VeicoloAMotore {
    boolean funzionante;
     String modello;
    VeicoloAMotore() {}
    VeicoloAMotore(String modello){
     funzionante=true;
     this.modello=modello;
     }
potrai scrivere :
VeicoloAMotore v1 = new VeicoloAMotore();
e v1 avra' la variabile funzionante settata a false e modello che punta
a null
oppure VeicoloAMotore v2 = new VeicoloAMotore("FIAT");
e allora la variabile funzionante sara' ancora false ma modello adesso
puntera' la stringa FIAT
Se sei ai primi passi con Java mi permetto di consigliarti di leggere
un buon libro invece di andare a tentativi. Prova Beginning Java 1.5 di
Ivor Horton

Alessio O. ha scritto:

MMmm la tua domanda NON e' chiara.
Come sarebbe a dire "replicare" il costruttore?
Io di costruttore ne vedo SOLO UNO nella tua classe.
Se ti riferisci al costruttore di default
VeicoloAMotore() {}
ti ricordo che il costruttore di default ti viene "regalato" dal
compilatore SOLO SE NON NE SCRIVI UNO TUO. Se lo rivuoi te lo devi
scrivere a mano.
Avendo questo:
 public class VeicoloAMotore {
    boolean funzionante;
     String modello;


Ivor Horton
Grazie del consiglio, lo leggero' senz'altro. Purtroppo ora ho la
scadenza di un esame a giorni, e devo fare in fretta quel che posso.
Poi avro' il tempo di appassionarmi :-)


 Poi avro' il tempo di appassionarmi :-)
Certo che siete proprio forti!
Volete superare gli esami senza conoscere almeno decentemente
gli argomenti trattati nel corso...
Ma che cavolo ci andate a fare all'universita'?! Per il "pezzo di carta"?!
Povera Italia!
Scusate lo sfogo...
Ciao!
Roberto
PS. In bocca al lupo per l'esame (spero che ti boccino cosi'
potrai studiare di piu' e meglio per il prossimo appello!)

 puntera' la stringa FIAT
Scusa perché nel secondo caso funzionante è false?
Grazie.
Michele Giodano

 potrai studiare di piu' e meglio per il prossimo appello!)
Quoto.
Un po' brutale, quindi scusate anche me
Saluti
CarMas

Capirai ben presto che non è buona norma mettere public gli attributi
di una classe

di una classe
Perfetto, quindi seguo la regola generale dei metodi getter e setter
anche nel creare un nuovo oggetto passando le variabili dal
costruttore invece che esplicitamente dagli attributi.
Grazie mille, anche a quelli un po' imbronciati che evidentemente si
sono dimenticati di cosa puo' succedere durante gli studi
universitari.


Capirai ben presto che non č buona norma mettere public gli attributi di una 
classe
Domanda cretina: non ho mai capito perchč.
Quale č il motivo per cui si ritiene preferibile scrivere cosě:
private int attributo;
public int attributo()
 { return attributo;}
e richiamare, dall'esterno, int a=classe.attributo(); anzichč, piů 
semplicente, rendere public attributo e fare int a=attributo;?

 semplicente, rendere public attributo e fare int a=attributo;?
A parte che dovresti comunque scrivere: int a = classe.attributo;...
Supponiamo che le specifiche del programma richiedano, per la
tua classe, che l'attributo "attributo" possa assumere solo valori
entro uno specifico intervallo [a,b].
Ti chiedo: come fai a garantire che sia sempre soddisfatta questa
condizione invariante se metti l'attributo public?
Ciao!
Roberto

> prossimo appello!)
C> Quoto.
C> Un po' brutale, quindi scusate anche me
Non c'è due senza tre.
-- 
 /\            ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
  //--\ | | \|  |   Integralista GNUslamico  
\/		    e allevatore di bug da competizione

 writes:
M> Capirai ben presto che non è buona norma mettere public gli
M> attributi di una classe
M> Domanda cretina: non ho mai capito perchè.
M> Quale è il motivo per cui si ritiene preferibile scrivere così:
Prima di tutto i compilatori attuali se trovano la forma
public final void setAttributo(UnTipoACaso attributo) {
   this.attributo = attributo;
}
ottimizzano da loro in una assegnazione senza chiamata. 
Idem per il getter.
Bello, dirai, ma allora che servono ?
Anche se  tu non  stai facendo un  bean, quindi  non ti serve  che gli
attributi vengano identificati attraverso il ritrovamento dei getter e
setter (cosa che  permette di fare attributi write  only -utili a naso
solo in casi patologici- e read only -più utili-) la cosa ha ancora la
sua utilità.
I setter permettono, ad esempio, di verificare che il valore assegnato
sia valido.
Insieme  ai getter  ti permettono  di  nascondere come  hai deciso  di
memorizzare il valore.
E questa è  la teoria. Non sempre avrai  situazioni particolari in cui
l'attributo sarà conservato in maniera  strana, nel 99% dei casi avrai
che una variabile privata di tipo UnTipoACaso sarà usata per tenere il
valore che è passato al setter e prelevato dal getter.
Solo immaginati questo scenario.
Pubblichi  (anche solo  in un  gruppo  ristretto) una  classe con  una
variabile pubblica.
Ti rendi conto che devi mettere un controllo sui valori leciti (per il
buon funzionamento  della classe) per quella  variabile all'interno di
quelli che può  assumere il tipo.
Quindi metti la variabile privata con un getter ed un setter.
Bingo. TUTTO il  codice che usa quella classe  va modificato, non solo
il codice che andava in bomba.
Se invece tu fossi partito con i getter e setter subito avresti potuto
aggiungere  i controlli  senza dover  toccare il  codice  che funziona
bene.
Tutto qui.


 writes:
MG> Scusa perché nel secondo caso funzionante è false?  Grazie.
Posso rispondere  "è scritto sul  manuale" ? Controlla la  parte sulla
inizializzazione dei campi di classe.


 Poi avro' il tempo di appassionarmi :-)
E' evidente che non hai la piu' pallida idea di quello che stai facendo
con Java...
ora, io mi ricordo di avere fatto piu' di un 'esame senza sapere tutto
alla perfezione,
e qualcuno anche con dei seri "buchi" e un po' di confusione.. ma voler
dare un esame
di java quando sei a questo livello mi sembra davvero assurdo e
inutile...

Michele Giordano ha scritto:

Svista mia, sorry, non avevo visto
 funzionante = true
 nel secondo costruttore

 Scusa perché nel secondo caso funzionante è false?
Imho e' un lapsus.
Saluti
CarMas

inutile...
L'esame non e' mica domani! ;-)
Grazie comunque della puntualizzazione.


 universitari.
Che può succedere, di grazia?

 semplicente, rendere public attributo e fare int a=attributo;?
Se metti in moto lo spirito di osservazione proprio sul tuo esempio
noterai che, senza volerlo, hai realizzato un attributo in sola
lettura.
E' un buon inizio incipit per cominciare a capire.

>Che puň succedere, di grazia?
Che le cose non vanno sempre come si vorrebbe :-)


 Che le cose non vanno sempre come si vorrebbe :-)
Eh, allora sapessi dopo...