Discussion :

[g_rare]

http://java.sun.com/j2se/1.3/docs/ap...t.html#clone()

Copying an object will typically entail creating a new instance of its class, but it also may require copying of internal data structures as well. No constructors are called.

• http://jakarta.apache.org/commons/la....Serializable)
  

  SerializationUtils
  
  public static Object clone(Serializable object)
  
  Deep clone an Object using serialization.
  
  This is many times slower than writing clone methods by hand on all objects in your object graph. However, for complex object graphs, or for those that don't support deep cloning this can be a simple alternative implementation. Of course all the objects must be Serializable.
  
  Parameters:
  object - the Serializable object to clone
  Returns:
  the cloned object
  Throws:
  SerializationException - (runtime) if the serialization fails

• http://jakarta.apache.org/commons/lang/api-release/org/apache/commons/lang/ArrayUtils.html#clone(java.lang.Object[])
• http://java.sun.com/developer/Books/...a/Chapter3.pdf

[danyboy85]

Pour ton code sur la sérialisation, il manque des bloc try/finally afin de fermer correctement les flux.
Jette un coup d'oeil sur le tutoriel : java.io

OK merci

[mavina]

http://java.sun.com/j2se/1.3/docs/ap...t.html#clone()

• http://jakarta.apache.org/commons/la....Serializable)
• http://jakarta.apache.org/commons/lang/api-release/org/apache/commons/lang/ArrayUtils.html#clone(java.lang.Object[])
• http://java.sun.com/developer/Books/...a/Chapter3.pdf

Je n'ai jamais parlé d'appeler la methode clone()

Il peut tres bien faire

MonObjet copie=new MonObjet(objetACopier);

Tout simplement
Enfin, dans son cas c'est pas possible

Fred

[adiGuba]

(j'ai un peu tardé à poster)

Je suppose que tu dois venir de C++ où la copie d'objet est obligatoire dans ces cas là...

C'est quoi l'immuabilité ?

L'immuabilité est un des principales notions de Java (a mon sens en tout cas), et viens justement proposer une solution à ce style de problème.

Une classe immuable est une classe qui ne peut pas être modifié un fois qu'elle sont créée. On est obligé de créer une nouvelle instance...

C'est le cas d'un certain nombre de classe "conteneur", comme String, toutes les classes wrappers (Integer, Float, Double, Character...), Color, BigDecimal...


Les classes immuables se distinguent par un certain nombre de point :
La classe doit être final afin qu'on ne puissent pas en hérité (et potentiellement cassé l'immuabilité).
Tous les attributs devrait être déclaré final (afin d'être sûr qu'il ne soient pas modifié après l'initialisation) et private (afin qu'il ne soient pas modifié par une autre classe).
Aucune de ses méthodes ne modifient ses attributs (ou en tout cas ses attributs "utiles"). Donc pas de méthode set***()...
Si un attribut n'est pas lui-même immuable, on doit s'assurer de la recopie de sa valeur (avec clone() ou en créant un nouvel objet) et ne pas fournir la référence vers cet objet.



Si une classe est immuable, on peut alors l'utiliser simplement, sans aucune recopie ou cloneage, tout en étant sûr que sa valeur ne sera pas modifié à cause d'une référence qui traine... (c'est pour cela que String n'est pas cloneable)

Le petit bout de code suivant te montre bien cela, en comparant l'objet immuable Long et l'objet java.util.Date qui ne l'est pas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
public final class Main {
 
    private final Long longValue;
    private final Date dateValue;
 
    public Main(Long l, Date d) {
        this.longValue = l;
        this.dateValue = d;
    }
 
    @Override
    public String toString() {
        return longValue + " " + dateValue.getTime();
    }
 
    public static void main(String[] args) {
 
        long value = 0;
        Long longValue = new Long(value);
        Date dateValue = new Date(value);
 
        // On crée un objet avec les valeurs 0 0
        Main obj = new Main(longValue, dateValue);
 
        // On affiche l'objet 
        System.out.println( obj );    // 0 0
 
        // On modifie la valeur de l'objet 'longValue'
        // On est obligé d'en crée un nouveau :
        longValue = new Long( 15 );
 
        // On affiche l'objet (rien n'a changé) :
        System.out.println( obj );    // 0 0
 
 
        // On modifie la valeur de l'objet 'dateValue'
        // On n'est pas obligé d'en créer un nouveau
        // puisque la classe n'est pas immuable :
        dateValue.setTime( 15 );
 
        // On affiche l'objet (qui a été modifié) :
        System.out.println( obj );    // 0 15
    }
}

Pour éviter ce type de problème, il aurait fallut créer une nouvel objet Date dans le constructeur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
    public Main(Long l, Date d) {
        this.longValue = l;
        this.dateValue = new Date(d.getTime());
    }

Le gros avantage de cette méthode par rapport à la recopie d'objet modifiable, c'est que tu ne crées une nouvelle instance que lorsque tu en as réellement besoin, et que tu évites un grand nombre de copie inutile...


Pour en revenir à ton problème : quel sont les types des objets que tu devras gérer ?


a++


PS : Juste une remarque :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
String s="coucou";
s=s+" c'est moi";

c'est équivalent à :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
String s="coucou";
s=new String("coucou c'est moi");

En fait c'est équivalent à ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
String s="coucou";
s = new StringBuffer(s).append(" c'est moi").toString();

Mais le résultat est le même : on a bien une nouvelle instance de String...

[divxdede]

Le problème c'est que mon objet comporte des attributs de types différents : String ,int et des types Objet.

Or , la classe String par exemple, n'implémente pas l'interface Cloneable, ce qui signifie que pour cloner une valeur de type String, je suis obligé de faire dériver la classe String en une classe String1 qui va implémenter la classe Cloneable et tous mes attributs de type String devront être de type String1 : extrémement lourd...

La classe String est un faux problème concernant le clonage. Etant une classe immuable, ton clone peut posséder la meme reference mais dans le cas d'un deepClone(). Puisque personne ne peut modifier sa valeur.

[divxdede]

Si tout tes fields sont serializable, comme proposé quelques messages plus haut (zut je suis grillé ) tu peut alors utiliser une serialization/deserialization.

L'avantage avec ce mécanisme c'est qu'il respecte le graphe de reference.
C'est a dire que si ta classe A reference dans 2x champs le meme objet X
alors le clone aura une copie de X mais ces deux champs auront eux aussi la meme instance X.

A noté qu'un clone par serialization est trés couteux.