[Java] metodo clone

[WhiteWolf42]

ciao a tutti, ho un lapsus ...

per clonare un'oggetto, cioè restituire un'istanza della medesima classe con i campi valorizzati con i medesimi contenuti, è sufficiente effettuare l'override del motodo clone() in questo modo

public Object clone() throws CloneNotSupportedException {
return super.clone();
}

implementando l'interfaccia Cloneable ???

o devo campo per campo assegnare i dati a un nuovo oggetto e restituire quello ??

[m.distrutti]

public Object clone() throws CloneNotSupportedException {
return super.clone();
}


e' giusto per una clonazione superficiale

[WhiteWolf42]

public Object clone() throws CloneNotSupportedException {
return super.clone();
}


e' giusto per una clonazione superficiale

spiegati meglio per favore ...

[m.distrutti]

certo scusami ma prima di entrare nel dettaglio ho preferito fare delle prove per non dirti qualche cacchiata :)

allora abbiamo una classe Persona :
public class Persona implements Cloneable{
String nome;
String cognome;
int eta;
Cane cagnolino = new Cane("mio"); // per default si chiama mio il cane

public Persona(String nome, String cognome, int eta) {
this.nome = nome;
this.cognome = cognome;
this.eta = eta;
}

public Object clone(){
try{
return super.clone(); //richiamato il clone di object
}catch(CloneNotSupportedException e){
return null;
}
}
}
che implementa l'interfaccia e un attributo il cui tipo e' di un altra Classe(Cane)


public class mainClass {
public static void main(String args[]){
Persona marco = new Persona("Marco","Distrutti",20);
Persona claudio = (Persona)marco.clone();
claudio.cagnolino.nome = "ops";
System.out.println(marco.cagnolino.nome + " " + claudio.cagnolino.nome);
}
}

il clone di Object non crea un altra istanza per le Classi definite da programma percio i due oggetti clonati si riferiranno alla stessa istanza Cane per tanto nell'esempio da me riportato dopo aver modificato claudio.cagnolino.nome , ne influira anche marco.cagnolino.nome , cmq non solo per le classi definite da programma anche Point ne e' un esempio

per sicurezza qui c'e' una buona spiegazione
http://www.dis.uniroma1.it/~liberato/laboratorio/clone/clone.html

EDIT: in pratica i due oggetti clonati condividono gli stessi riferimenti ad attributi oggetto

[WhiteWolf42]

ok, grazie ... ma porca *** che palle ... !!! e tranquillamente sulla JDK c'è scritto l'opposto !!! mmm che nervi !!! vabbhe ... vado di reflection e via marciare !!!

[mad_hhatter]

certo scusami ma prima di entrare nel dettaglio ho preferito fare delle prove per non dirti qualche cacchiata :)

allora abbiamo una classe Persona :
public class Persona implements Cloneable{
String nome;
String cognome;
int eta;
Cane cagnolino = new Cane("mio"); // per default si chiama mio il cane

public Persona(String nome, String cognome, int eta) {
this.nome = nome;
this.cognome = cognome;
this.eta = eta;
}

public Object clone(){
try{
return super.clone(); //richiamato il clone di object
}catch(CloneNotSupportedException e){
return null;
}
}
}
che implementa l'interfaccia e un attributo il cui tipo e' di un altra Classe(Cane)


public class mainClass {
public static void main(String args[]){
Persona marco = new Persona("Marco","Distrutti",20);
Persona claudio = (Persona)marco.clone();
claudio.cagnolino.nome = "ops";
System.out.println(marco.cagnolino.nome + " " + claudio.cagnolino.nome);
}
}

il clone di Object non crea un altra istanza per le Classi definite da programma percio i due oggetti clonati si riferiranno alla stessa istanza Cane per tanto nell'esempio da me riportato dopo aver modificato claudio.cagnolino.nome , ne influira anche marco.cagnolino.nome , cmq non solo per le classi definite da programma anche Point ne e' un esempio

per sicurezza qui c'e' una buona spiegazione
http://www.dis.uniroma1.it/~liberato/laboratorio/clone/clone.html

EDIT: in pratica i due oggetti clonati condividono gli stessi riferimenti ad attributi oggetto

beh è normale: cagnolino è una reference e il clone ne fa una copia... quindi il clone di cagnolino avrà lo stesso valore dell'originale, cioè punterà al medesimo oggetto.

basta ridefinire il metodo clone per chiamare ricorsivamente il clone sui membri di tipo reference (come scritto nella doc della classe java.lang.Object)

[k0nt3]

e tranquillamente sulla JDK c'è scritto l'opposto !!!

ne dubito fortemente :fagiano:

[WhiteWolf42]

ne dubito fortemente :fagiano:

riguardando bene (con il supporto di un colega che inglese lo mastica a go go) effettivamente la spiegazione è più chiara ... cmq abbastanza fuorviante ...

vabbhe ... poco importa ... cmq con un po' di reflection ho ovviato al problema ... per info collettiva posto il codice ..

hidden
manca il metodo checkCase ... ma alla fine restituisce solo il nome del campo con i caratteri "compatibili" per la concatenazione per i metodi set e get

[m.distrutti]

beh è normale: cagnolino è una reference e il clone ne fa una copia... quindi il clone di cagnolino avrà lo stesso valore dell'originale, cioè punterà al medesimo oggetto.

basta ridefinire il metodo clone per chiamare ricorsivamente il clone sui membri di tipo reference (come scritto nella doc della classe java.lang.Object)

si certo mi riferivo a quello postato da lui non dicevo che era impossibile farlo :S, te parli della clonazione profonda

[WhiteWolf42]

ovviamente ... anche perchè una clonazione superficiale è una cagata ... basta fare un banale assegnamento ... quello che volevo ottenere io erano 2 istanze reali e distinte con campi contenenti i medesimi valori !!

[k0nt3]

riguardando bene (con il supporto di un colega che inglese lo mastica a go go) effettivamente la spiegazione è più chiara ... cmq abbastanza fuorviante ...

vabbhe ... poco importa ... cmq con un po' di reflection ho ovviato al problema ... per info collettiva posto il codice ..

...
manca il metodo checkCase ... ma alla fine restituisce solo il nome del campo con i caratteri "compatibili" per la concatenazione per i metodi set e get

è ancora sbagliato :D a parte il fatto che potresti implementarlo in una classe statica.. il che avrebbe più senso IMHO
l'errore è che basta chiamare setProperty solo se il campo è di tipo primitivo, mentre se si tratta di un tipo reference devi a sua volta clonarlo prima dell'assegnamento. da qui il nome: clonazione profonda ;)

di solito comunque non conviene creare un metodo generico, ma semplicemente si fa l'override del metodo clone e si implementa la clonazione profonda specifica per la classe in questione

[WhiteWolf42]

di solito comunque non conviene creare un metodo generico, ma semplicemente si fa l'override del metodo clone e si implementa la clonazione profonda specifica per la classe in questione

c'è un problemino ... io devo "mappare" una serie di tabelle di un db (come orami penso sia evidente) ... il problema è che le tabelle sono 87 ... e qualla che ha meno campi ne ha 12 ... come puoi immaginare ... non passerebbe più ... e poi, in caso di modifica alla struttura del DB dovrei fare un lavoraccio ... e tanti saluti alla riusabilità del codice e alla filosofia object oriented ....

[k0nt3]

c'è un problemino ... io devo "mappare" una serie di tabelle di un db (come orami penso sia evidente) ... il problema è che le tabelle sono 87 ... e qualla che ha meno campi ne ha 12 ... come puoi immaginare ... non passerebbe più ... e poi, in caso di modifica alla struttura del DB dovrei fare un lavoraccio ... e tanti saluti alla riusabilità del codice e alla filosofia object oriented ....

beh mi sembra implicito che tu debba fare un lavoraccio in ogni caso :p
solo una cosa.. perchè è importante clonare gli oggetti nel tuo caso?

[WhiteWolf42]

beh mi sembra implicito che tu debba fare un lavoraccio in ogni caso :p
solo una cosa.. perchè è importante clonare gli oggetti nel tuo caso?

perchè a un certo punto del flusso, in una serie di determinate condizioni, devo creare una serie di record identici, ma che si differenziano per alcuni campi ... Visto che il record padre è sempre valorizzato ho pensato: faccio un controllo, se il controllo è positivo lo clono e cambio solo il campo che mi serve, al posto di farmi tutto il lavoraccio inutilmente .. mi sa che mi tocca .. ho trovato anche

Tuttavia una soluzione efficente si ha implementando l'interfaccia Cloneable e ridefinendo il metodo clone per ogni classe utilizzata.

[k0nt3]

perchè a un certo punto del flusso, in una serie di determinate condizioni, devo creare una serie di record identici, ma che si differenziano per alcuni campi ... Visto che il record padre è sempre valorizzato ho pensato: faccio un controllo, se il controllo è positivo lo clono e cambio solo il campo che mi serve, al posto di farmi tutto il lavoraccio inutilmente .. mi sa che mi tocca ..
uhm non so come è stata implementata la cosa, ma io mi costruirei dei metodi che a partire dal DB generano degli oggetti (uno per tupla), mentre quando devo creare un oggetto lo scrivo direttamente nel DB. in questo modo la prossima volta che leggo il DB avrò il nuovo oggetto che sarà diverso da tutti gli altri.
tutto questo ovviamente se non usi la persistenza di JavaEE (vedi hibernate), forse per una struttura così complessa non pensata per JavaEE è un pò complicato.

ho trovato anche

Tuttavia una soluzione efficente si ha implementando l'interfaccia Cloneable e ridefinendo il metodo clone per ogni classe utilizzata.


che è quello che avevo suggerito prima ;)

[WhiteWolf42]

il problema è che dobbiamo ridurre al minimo indispensabile gli accessi al DB ... sono mole di dati enormi. per caricare un flusso ci fogliono 10/15h ... quindi bisogna ottimizzare al massimo il programma ... cmq lavoretto da 10 minuti con ultraedit ed è fatta ... si, ma che soluzione di merda ...

ah ... piccolo dettaglio che mi era sfuggito ... sn sulla jdk 1.4 :muro: :muro:

PS: lasciamo stare ... qui standard 0, analisi funzionale -2, informazioni ... -100

[k0nt3]

se bisogna ridurre al minimo gli accessi al db allora si potrebbe usare un pattern di tipo proxy (che gestisce le letture e le scritture in maniera asincrona e mantiene una cache dei dati). ma qui mi sa che ti rimane il problema di clonare gli oggetti :fagiano:
potrebbe interessarti questa tecnica:
http://en.wikipedia.org/wiki/Copy-on-write
e quest'altra per la deep copy:
http://javatechniques.com/blog/faster-deep-copies-of-java-objects/
http://www.javaworld.com/javaworld/javatips/jw-javatip76.html?page=1

[WhiteWolf42]

impossibile effettuare lettura asincrona per un problema di cui non te ne parlo perchè mi vergogno aver implementato codice così !!!

[k0nt3]

impossibile effettuare lettura asincrona per un problema di cui non te ne parlo perchè mi vergogno aver implementato codice così !!!
non farla così tragica :p
quando si lavora con strumenti del genere non è facile arrivare a una soluzione elegante :O

ps. perchè usi ultraedit e non eclipse per esempio?

[WhiteWolf42]

non farla così tragica :p
quando si lavora con strumenti del genere non è facile arrivare a una soluzione elegante :O

ps. perchè usi ultraedit e non eclipse per esempio?

uso eclipse (se no sarebbe da spararsi), UE lo uso per formattare meglio del testo, ha degli strumenti di formato e registrazione delle macro molto utili ...

[k0nt3]

beh con eclipse potresti migliorare la situazione a colpi di refactoring :)

[WhiteWolf42]

beh con eclipse potresti migliorare la situazione a colpi di refactoring :)

nn è la scrittura del codice il problema (magari ...) è proprio la metalità (moltro approssimantiva) con cui questo programma è stato pensato e realizzato ... tutto a compartimenti stagni, ogniuno faceva quel che voleva ... io sono arrivato alla fine e ci sto smadonnando da 3 settimane ... è più il tempo che fixo gli errori altrui che quello che pesso a scrivere il mio codice ... poi qui (cm ti ho detto) le parole "analisi funzionale", "test di sviluppo", "test di non regressione" non sanno nemmeno cosa siano ...

per cui mi trovo a dover fare il deploy direttamente in produzione (stasera) di un programma che non ho mai potuto testare, se non con un flusso "costruito" che mi ha dato per forza esito positivo ... vorrei anche vedere ... me lo sono costruito ad oc ... cmq oggi si attaccano al cazzo, io alle 18 esco ... e se lo smazzano loro ... fanculo !

[k0nt3]

il tuo ragionamento non fa una piega :asd:
comunque dai un'occhiata ai link di prima sulla deep copy, se gli oggetti sono serializzabili te la cavi abbastanza facilmente

[WhiteWolf42]

quelli nn riesco a vederli, sn dietro proxy e mi blinda siti a minchia ... figurati che HWUp nn me lo blinda, tutti i forum di SoftAir nn me li blinda .... il forum della comunity p2p + grossa d'italia nn me lo blinda ... ,ma i forum IT si ... !!

[k0nt3]

in pratica suggerisce di fare una roba tipo:

import java.io.*;
import java.util.*;
import java.awt.*;
public class ObjectCloner
{
// so that nobody can accidentally create an ObjectCloner object
private ObjectCloner(){}
// returns a deep copy of an object
static public Object deepCopy(Object oldObj) throws Exception
{
ObjectOutputStream oos = null;
ObjectInputStream ois = null;
try
{
ByteArrayOutputStream bos =
new ByteArrayOutputStream(); // A
oos = new ObjectOutputStream(bos); // B
// serialize and pass the object
oos.writeObject(oldObj); // C
oos.flush(); // D
ByteArrayInputStream bin =
new ByteArrayInputStream(bos.toByteArray()); // E
ois = new ObjectInputStream(bin); // F
// return the new object
return ois.readObject(); // G
}
catch(Exception e)
{
System.out.println("Exception in ObjectCloner = " + e);
throw(e);
}
finally
{
oos.close();
ois.close();
}
}

}


non mi piace molto quel throws Exception, ma con eclipse non dovresti avere problemi a sostituirlo con qualcosa di più sensato.
poi non ho provato questo codice, ma probabilmente al posto di Object potresti usare direttamente Serializable in modo che a tempo di compilazione riesci ad accorgerti se l'oggetto che stai passando implementa Serializable o meno.
l'altro link invece parlava di possibili ottimizzazioni, perchè come metodo è un pò più lento della reimplementazione di Object.clone()

[WhiteWolf42]

cioè ... se ho capito bene .... fa la copia brutalmente byte per byte ?????

[k0nt3]

cioè ... se ho capito bene .... fa la copia brutalmente byte per byte ?????

in pratica sì :fagiano: da qui l'esigenza di pensare a delle ottimizzazioni