Newsgroup: it.comp.java
Titolo: assegnare un diverso ID numerico ad ogni diversa istanza di una  classe

Buongiorno a tutti!!
Buongiorno ad Andrea Francia :)
Vorrei sapere come posso "assegnare un diverso ID numerico ad ogni
diversa istanza di una classe",
un piccolo esempio:
creao un array (o una lista se prefrite) di classe Prodotto
Prodotto[] unProdotto = new Prodotto[5];
e vorrei che ognuno di questi 'unProdotto', possieda un campo
private int IDnumerico
che sia diverso da tutti gli altri
unProdotto[0].getID() == sarà uguale a 101
unProdotto[1].getID() == sarà uguale a 102
unProdotto[2].getID() == sarà uguale a 103
ecc ecc
Sapete aiutarmi ?
Grazie a tutti
Buona giornata

Giordano ha scritto:

Ciao,
...mai letto un libro di programmazione Java? :)
E' il classico esempio di uso degli attributi statici.
public class Prodotto {
   private static int nextId = 0;
   private int id;
   public Prodotto() {
 
this.id
 = nextId++;
   }
   public int getId() {
     return 
this.id
;
   }
}
(occhio che l'ho scritta di getto...non ho provato a compilarla, quindi 
qualche errore di sintassi è possible)
Ciao
   Lucio
-- 
Lucio Benfante
JUG Padova           
http://www.parancoe.org
 ...have a look at it!
www.jugpadova.it
 
http://www.jugevents.org

 Buongiorno ad Andrea Francia :)
Uh ... Buongiorno a te, ci conosciamo?
-- 
Andrea Francia
http://www.andreafrancia.it/

 diversa istanza di una classe",
soluzione grezza: contatore statico.
soluzione elegante: factory method.
-- 
 Fino all'anno scorso avevo un solo difetto. Ero presuntuoso.
http://softvalley.blogspot.com
http://www.flickr.com/photos/marko_po/


Uhm... factory method: è una di quelle "cose" che spesso leggo qui, ma
non ho idea di cosa sia..
..altro esempio è la "cosa" chiamata 'hibernate'.
Farò un giro su it.wikipedia

 soluzione elegante: factory method.
Ok, rootkit...visto che Giordano sembra interessato...io ho fatto vedere 
la soluzione "grezza"...perchè non ci fai vedere tu la soluzione "elegante"?


 "elegante"?
Il fatto che sia "elegante" andrebbe dimostrato.
Il fatto che sia un Design Pattern della GoF non vuol dire che sia una 
soluzione che si applica a tutti i problemi.


Sono curioso di vedere questa eleganza,
senz'altro la via del campo statica è molto diretta e semplice..
Io ho sempre interpretato la parola "elegante" come un qualcosa di
diretto ed alternativo alla via più comune.
Ancora non ho trovato esempi di factory method applicati
all'assegnamento di un id numerico.
Se qualcuno me ne può fornire uno, o anche il linka a questo,
gli sarò molto grato.
:)
Grazie

 ha 
scritto nel messaggio news:48217c8c$0$35956$4faf...@reader2.news.tin.it...

Non solo: IMHO un factory si dovrebbe usare soprattutto in casi in cui si 
vuole lavorare sull'interfaccia
di una classe, tralasciando il dettaglio dell'implementazione specifica; non 
so se abbia senso ricorrervi esclusivamente per generare un progressivo.
Scorpio.

 "elegante"?
come ho detto, la soluzione elegante è implemetare il pattern factory 
method, il quale come tutti i pattern creazionali si applica ove hai 
necessità di avere il controllo sulla creazione di un oggetto.
vuoi vedere un esempio?
public class Oggetto {
  private static int contatore;
  private int id;
  private Oggetto(int id) {
 
this.id
 = id;
  }
  public static Oggetto getInstance() {
    return new Oggetto(contatore++);


 soluzione che si applica a tutti i problemi.
nessuno ha detto che si applica a tutti i problemi. semplicemente i 
pattern creazionali si pongono i problemi di creazione degli oggetti e 
questo è un problema di creazione di un oggetto.
poi si può discutere a giornate intere su cosa sia una soluzione 
elegante, anche perchè se ci si impegna tutto diventa opinabile.


 
Infatti nessuno lo afferma. Piu' elegante puo' significare anche che si 
rende piu' agevole nel caso di ulteriori modifiche: ad esempio se vuoi 
ottenere l'id interrogando una sequenza di un database.

 so se abbia senso ricorrervi esclusivamente per generare un progressivo.
se vai a vedere, fra gli esempi della sua applicazione ci sono anche 
casi simili a quello descritto. casi cioè dove la classe deve essere 
inizializzata in modo rigoroso.
poi, se vuoi, si può discutere sui vantaggi e svantaggi di porsi sempre 
il problema dell'ingegnerizzazione anche su problematiche apparentemente 
semplici. nel caso di specie la domanda descriveva un problema 
"esemplare", sicuramente semplice dal punto di vista teorico: nel mondo 
reale, però, è molto probabile trovarsi in una situazione diversa come 
(ad esempio) dover utilizzare l'ioc container di spring per creare 
l'oggetto, o semplicemente doverlo iniettare in un'altro. ecco che la 
soluzione ingegnerizzata ti torna comoda.


 }
Dato che si tratta di un factory method un nome del tipo newInstance() o 
create() mi sembra piu' appropriato che getInstance().
-- 
Andrea Francia
alias rm='trash' #use trash command instead of removing
rm -Rfv file     #put the file in the KDE trashcan
http://www.andreafrancia.it/trash

 elegante, anche perchè se ci si impegna tutto diventa opinabile.
Ma sì, perché il concetto di eleganza è sfuggevole e opinabile.
Proprietà più interessanti per confrontare due soluzioni sono la 
semplicità, la robustezza e l'estensibilità.


 pattern.
più che un esempio estremo direi che è un esempio balordo
è come mostrare cosa si deve fare per piantare un chiodo col
cacciavite per dimostrare fin dove può arrivare l'uso sconsiderato dei
cacciaviti.
i pattern sono soluzioni a problemi precisi, se applichi il pattern
dove non c'è il problema ovviamente il risultato ottenuto è quantomeno
ridicolo, ma anche sbagliato.
il problema su cui applicare il pattern devi individuarlo e non
inventartelo.