Penser en Java

Quand on passe une référence à une méthode, on pointe toujours sur le même objet. Un simple test le démontre :

//: appendixa:PassReferences.java
// Le passage de références.

public class PassReferences {
  static void f(PassReferences h) {
    System.out.println("h inside f(): " + h);
  }
  public static void main(String[] args) {
    PassReferences p = new PassReferences();
    System.out.println("p inside main(): " + p);
    f(p);
  }
} ///:~

La méthode toString() est automatiquement appelée dans l'instruction print, dont PassReferences hérite directement de Object comme la méthode toString() n'est pas redéfinie. La version toString() de Object est donc utilisée, qui affiche la classe de l'objet suivie de l'adresse mémoire où se trouve l'objet (non pas la référence, mais bien là où est stocké l'objet). La sortie ressemble à ceci :

p inside main(): PassReferences@1653748
h inside f(): PassReferences@1653748

On peut constater que p et h référencent bien le même objet. Ceci est bien plus efficace que de créer un nouvel objet PassReferences juste pour envoyer un argument à une méthode. Mais ceci amène une importante question.

XVIII-A-1. Aliasing▲

//: appendixa:Alias1.java
// Aliasing : deux références sur un même objet.

public class Alias1 {
  int i;
  Alias1(int ii) { i = ii; }
  public static void main(String[] args) {
    Alias1 x = new Alias1(7);
    Alias1 y = x; // Assigne la référence.
    System.out.println("x: " + x.i);
    System.out.println("y: " + y.i);
    System.out.println("Incrementing x");
    x.i++;
    System.out.println("x: " + x.i);
    System.out.println("y: " + y.i);
  }
} ///:~

Alias1 y = x; // Assigne la référence.

x.i++

x: 7
y: 7
Incrementing x
x: 8
y: 8

//: appendixa:Alias2.java
// Les appels de méthodes aliassent implicitement
// leurs arguments.

public class Alias2 {
  int i;
  Alias2(int ii) { i = ii; }
  static void f(Alias2 reference) {
    reference.i++;
  }
  public static void main(String[] args) {
    Alias2 x = new Alias2(7);
    System.out.println("x: " + x.i);
    System.out.println("Calling f(x)");
    f(x);
    System.out.println("x: " + x.i);
  }
} ///:~

x: 7
Calling f(x)
x: 8

En résumé : tous les passages d'arguments en Java se font par référence. C'est-à-dire que quand on passe « un objet », on ne passe réellement qu'une référence à un objet qui vit en dehors de la méthode ; et si des modifications sont faites sur cette référence, on modifie l'objet extérieur. De plus :

• l'aliasing survient automatiquement durant le passage d'arguments ;
• il n'y a pas d'objets locaux, que des références locales ;
• les références ont une portée, les objets non ;
• la durée de vie d'un objet n'est jamais un problème en Java ;
• le langage ne fournit pas d'aide (tel que « const ») pour éviter qu'un objet ne soit modifié (c'est-à-dire pour se prémunir contre les effets négatifs de l'aliasing).

Si on ne fait que lire les informations d'un objet et qu'on ne le modifie pas, la forme la plus efficace de passage d'arguments consiste à passer une référence. C'est bien, car la manière de faire par défaut est aussi la plus efficace. Cependant, on peut avoir besoin de traiter l'objet comme s'il était « local » afin que les modifications apportées n'affectent qu'une copie locale et ne modifient pas l'objet extérieur. De nombreux langages proposent de créer automatiquement une copie locale de l'objet extérieur, à l'intérieur de la méthode  href="#fn79" name="fnB79"> (63). Java ne dispose pas de cette fonctionnalité, mais il permet tout de même de mettre en œuvre cet effet.

XVIII-B-1. Passage par valeur▲

XVIII-B-2. Clonage d'objets▲

//: appendixa:Cloning.java
// L'opération clone() ne marche que pour quelques
// composants de la bibliothèque Java standard.
import java.util.*;

class Int {
  private int i;
  public Int(int ii) { i = ii; }
  public void increment() { i++; }
  public String toString() { 
    return Integer.toString(i); 
  }
}

public class Cloning {
  public static void main(String[] args) {
    ArrayList v = new ArrayList();
    for(int i = 0; i < 10; i++ )
      v.add(new Int(i));
    System.out.println("v: " + v);
    ArrayList v2 = (ArrayList)v.clone();
    // Incrémente tous les éléments de v2 :
    for(Iterator e = v2.iterator();
        e.hasNext(); )
      ((Int)e.next()).increment();
    // Vérifie si les éléments de v ont été modifiés :
    System.out.println("v: " + v);
  }
} ///:~

v: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
v: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

XVIII-B-3. Rendre une classe cloneable▲

   Integer x = new Integer(1);
    x = x.clone();

interface Cloneable {}

if(myReference instanceof Cloneable) // ...

//: appendixa:LocalCopy.java
// Créer des copies locales avec clone().
import java.util.*;

class MyObject implements Cloneable {
  int i;
  MyObject(int ii) { i = ii; }
  public Object clone() {
    Object o = null;
    try {
      o = super.clone();
    } catch(CloneNotSupportedException e) {
      System.err.println("MyObject can't clone");
    }
    return o;
  }
  public String toString() {
    return Integer.toString(i);
  }
}

public class LocalCopy {
  static MyObject g(MyObject v) {
    // Passage par référence, modifie l'objet extérieur :
    v.i++;
    return v;
  }
  static MyObject f(MyObject v) {
    v = (MyObject)v.clone(); // Copie locale
    v.i++;
    return v;
  }
  public static void main(String[] args) {
    MyObject a = new MyObject(11);
    MyObject b = g(a);
    // On teste l'équivalence des références,
    // non pas l'équivalence des objets :
    if(a == b) 
      System.out.println("a == b");
    else 
      System.out.println("a != b");
    System.out.println("a = " + a);
    System.out.println("b = " + b);
    MyObject c = new MyObject(47);
    MyObject d = f(c);
    if(c == d) 
      System.out.println("c == d");
    else 
      System.out.println("c != d");
    System.out.println("c = " + c);
    System.out.println("d = " + d);
  }
} ///:~

v = (MyObject)v.clone();

a == b
a = 12
b = 12
c != d
c = 47
d = 48

XVIII-B-4. Le mécanisme de Object.clone( )▲

//: appendixa:Snake.java
// Teste le clonage pour voir si la destination
// des références sont aussi clonées.

public class Snake implements Cloneable {
  private Snake next;
  private char c;
  // Valeur de i == nombre de segments
  Snake(int i, char x) {
    c = x;
    if(--i > 0)
      next = new Snake(i, (char)(x + 1));
  }
  void increment() {
    c++;
    if(next != null)
      next.increment();
  }
  public String toString() {
    String s = ":" + c;
    if(next != null)
      s += next.toString();
    return s;
  }
  public Object clone() {
    Object o = null;
    try {
      o = super.clone();
    } catch(CloneNotSupportedException e) {
      System.err.println("Snake can't clone");
    }
    return o;
  }
  public static void main(String[] args) {
    Snake s = new Snake(5, 'a');
    System.out.println("s = " + s);
    Snake s2 = (Snake)s.clone();
    System.out.println("s2 = " + s2);
    s.increment();
    System.out.println(
      "after s.increment, s2 = " + s2);
  }
} ///:~

s = :a:b:c:d:e
s2 = :a:b:c:d:e
after s.increment, s2 = :a:c:d:e:f

XVIII-B-5. Cloner un objet composé▲

//: appendixa:DeepCopy.java
// Clonage d'un objet composé.

class DepthReading implements Cloneable {
  private double depth;
  public DepthReading(double depth) { 
    this.depth = depth;
  }
  public Object clone() {
    Object o = null;
    try {
      o = super.clone();
    } catch(CloneNotSupportedException e) {
      e.printStackTrace(System.err);
    }
    return o;
  }
}

class TemperatureReading implements Cloneable {
  private long time;
  private double temperature;
  public TemperatureReading(double temperature) {
    time = System.currentTimeMillis();
    this.temperature = temperature;
  }
  public Object clone() {
    Object o = null;
    try {
      o = super.clone();
    } catch(CloneNotSupportedException e) {
      e.printStackTrace(System.err);
    }
    return o;
  }
}

class OceanReading implements Cloneable {
  private DepthReading depth;
  private TemperatureReading temperature;
  public OceanReading(double tdata, double ddata){
    temperature = new TemperatureReading(tdata);
    depth = new DepthReading(ddata);
  }
  public Object clone() {
    OceanReading o = null;
    try {
      o = (OceanReading)super.clone();
    } catch(CloneNotSupportedException e) {
      e.printStackTrace(System.err);
    }
    // On doit cloner les références :
    o.depth = (DepthReading)o.depth.clone();
    o.temperature = 
      (TemperatureReading)o.temperature.clone();
    return o; // Transtypage en Object
  }
}

public class DeepCopy {
  public static void main(String[] args) {
    OceanReading reading = 
      new OceanReading(33.9, 100.5);
    // Maintenant on le clone :
    OceanReading r = 
      (OceanReading)reading.clone();
  }
} ///:~

XVIII-B-6. Copie profonde d'une ArrayList▲

//: appendixa:AddingClone.java
// Il faut apporter quelques modifications
// pour que vos classes soient cloneables.
import java.util.*;

class Int2 implements Cloneable {
  private int i;
  public Int2(int ii) { i = ii; }
  public void increment() { i++; }
  public String toString() {
    return Integer.toString(i);
  }
  public Object clone() {
    Object o = null;
    try {
      o = super.clone();
    } catch(CloneNotSupportedException e) {
      System.err.println("Int2 can't clone");
    }
    return o;
  }
}

// Une fois qu'elle est cloneable, l'héritage
// ne supprime pas cette propriété :
class Int3 extends Int2 {
  private int j; // Automatiquement dupliqué
  public Int3(int i) { super(i); }
}

public class AddingClone {
  public static void main(String[] args) {
    Int2 x = new Int2(10);
    Int2 x2 = (Int2)x.clone();
    x2.increment();
    System.out.println(
      "x = " + x + ", x2 = " + x2);
    // Tout objet hérité est aussi cloneable :
    Int3 x3 = new Int3(7);
    x3 = (Int3)x3.clone();

    ArrayList v = new ArrayList();
    for(int i = 0; i < 10; i++ )
      v.add(new Int2(i));
    System.out.println("v: " + v);
    ArrayList v2 = (ArrayList)v.clone();
    // Maintenant on clone chaque élément :
    for(int i = 0; i < v.size(); i++)
      v2.set(i, ((Int2)v2.get(i)).clone());
    // Incrémente tous les éléments de v2 :
    for(Iterator e = v2.iterator();
        e.hasNext(); )
      ((Int2)e.next()).increment();
    // Vérifie si les éléments de v ont été modifiés :
    System.out.println("v: " + v);
    System.out.println("v2: " + v2);
  }
} ///:~

//: appendixa:Compete.java
import java.io.*;

class Thing1 implements Serializable {}
class Thing2 implements Serializable {
  Thing1 o1 = new Thing1();
}

class Thing3 implements Cloneable {
  public Object clone() {
    Object o = null;
    try {
      o = super.clone();
    } catch(CloneNotSupportedException e) {
      System.err.println("Thing3 can't clone");
    }
    return o;
  }
}

class Thing4 implements Cloneable {
  Thing3 o3 = new Thing3();
  public Object clone() {
    Thing4 o = null;
    try {
      o = (Thing4)super.clone();
    } catch(CloneNotSupportedException e) {
      System.err.println("Thing4 can't clone");
    }
    // Clone aussi la donnée membre :
    o.o3 = (Thing3)o3.clone();
    return o;
  }
}

public class Compete {
  static final int SIZE = 5000;
  public static void main(String[] args) 
  throws Exception {
    Thing2[] a = new Thing2[SIZE];
    for(int i = 0; i < a.length; i++)
      a[i] = new Thing2();
    Thing4[] b = new Thing4[SIZE];
    for(int i = 0; i < b.length; i++)
      b[i] = new Thing4();
    long t1 = System.currentTimeMillis();
    ByteArrayOutputStream buf = 
      new ByteArrayOutputStream();
    ObjectOutputStream o =      new ObjectOutputStream(buf);
    for(int i = 0; i < a.length; i++)
      o.writeObject(a[i]);
    // Récupère les copies:
    ObjectInputStream in =      new ObjectInputStream(
        new ByteArrayInputStream(
          buf.toByteArray()));
    Thing2[] c = new Thing2[SIZE];
    for(int i = 0; i < c.length; i++)
      c[i] = (Thing2)in.readObject();
    long t2 = System.currentTimeMillis();
    System.out.println(
      "Duplication via serialization: " +
      (t2 &#150; t1) + " Milliseconds");
    // Maintenant on tente le clonage :
    t1 = System.currentTimeMillis();
    Thing4[] d = new Thing4[SIZE];
    for(int i = 0; i < d.length; i++)
      d[i] = (Thing4)b[i].clone();
    t2 = System.currentTimeMillis();
    System.out.println(
      "Duplication via cloning: " +
      (t2 &#150; t1) + " Milliseconds");
  }
} ///:~

Duplication via serialization: 940 Milliseconds
Duplication via cloning: 50 Milliseconds

Duplication via serialization: 710 Milliseconds
Duplication via cloning: 60 Milliseconds

Duplication via serialization: 770 Milliseconds
Duplication via cloning: 50 Milliseconds

XVIII-B-7. Supporter le clonage plus bas dans la hiérarchie▲

//: appendixa:HorrorFlick.java
// On peut implémenter le Clonage
// à n'importe quel niveau de la hiérarchie.
import java.util.*;

class Person {}
class Hero extends Person {}
class Scientist extends Person 
    implements Cloneable {
  public Object clone() {
    try {
      return super.clone();
    } catch(CloneNotSupportedException e) {
      // Ceci ne devrait jamais arriver :
      // la classe est Cloneable !
      throw new InternalError();
    }
  }
}
class MadScientist extends Scientist {}

public class HorrorFlick {
  public static void main(String[] args) {
    Person p = new Person();
    Hero h = new Hero();
    Scientist s = new Scientist();
    MadScientist m = new MadScientist();

    // p = (Person)p.clone(); // Erreur lors de la compilation
    // h = (Hero)h.clone(); // Erreur lors de la compilation
    s = (Scientist)s.clone();
    m = (MadScientist)m.clone();
  }
} ///:~

XVIII-B-8. Pourquoi cet étrange design ?▲

On pourrait penser que, pour supprimer le support du clonage, il suffit de rendre private la méthode clone(), mais ceci ne marchera pas, car on ne peut prendre une méthode de la classe de base et la rendre moins accessible dans une classe dérivée. Ce n'est donc pas si simple. Et pourtant, il est essentiel d'être capable de contrôler si un objet peut être cloné ou non. Une classe peut adopter plusieurs attitudes à ce propos :

1. L'indifférence. Rien n'est fait pour supporter le clonage, ce qui signifie que la classe ne peut être clonée, mais qu'une classe dérivée peut implémenter le clonage si elle veut. Ceci ne fonctionne que si Object.clone() traite comme il faut tous les champs de la classe ;
2. Implémenter clone(). Respecter la marche à suivre pour l'implémentation de Cloneable et redéfinir clone(). Dans la méthode clone() redéfinie, appeler super.clone() et intercepter toutes les exceptions (afin que la méthode clone() redéfinie ne génère pas d'exceptions) ;
3. Supporter le clonage conditionnellement. Si la classe contient des références sur d'autres objets qui peuvent ou non être cloneables (une classe conteneur, par exemple), la méthode clone() peut essayer de cloner tous les objets référencés, et s'ils génèrent des exceptions, relayer ces exceptions au programmeur. Par exemple, prenons le cas d'une sorte d'ArrayList qui essayerait de cloner tous les objets qu'elle contient. Quand on écrit une telle ArrayList, on ne peut savoir quelle sorte d'objets le programmeur client va pouvoir stocker dans l'ArrayList, on ne sait donc pas s'ils peuvent être clonés ;
4. Ne pas implémenter Cloneable, mais redéfinir clone() en protected, en s'assurant du fonctionnement correct du clonage pour chacun des champs. De cette manière, toute classe dérivée peut redéfinir clone() et appeler super.clone() pour obtenir le comportement attendu lors du clonage. Cette implémentation peut et doit invoquer super.clone() même si cette méthode attend un objet Cloneable (elle génère une exception sinon), car personne ne l'invoquera directement sur un objet de la classe. Elle ne sera invoquée qu'à travers une classe dérivée, qui, elle, implémente Cloneable si elle veut obtenir le fonctionnement désiré ;
5. Tenter de bloquer le clonage en n'implémentant pas Cloneable et en redéfinissant clone() afin de générer une exception. Ceci ne fonctionne que si toutes les classes dérivées appellent super.clone() dans leur redéfinition de clone(). Autrement, un programmeur est capable de contourner ce mécanisme ;
6. Empêcher le clonage en rendant la classe final. Si clone() n'a pas été redéfinie par l'une des classes parentes, alors elle ne peut plus l'être. Si elle a déjà été redéfinie, la redéfinir à nouveau et générer une exception CloneNotSupportedException. Rendre la classe final est la seule façon d'interdire catégoriquement le clonage. De plus, si on manipule des objets de sécurité ou dans d'autres situations dans lesquelles on veut contrôler le nombre d'objets créés, il faut rendre tous les constructeurs private et fournir une ou plusieurs méthodes spéciales pour créer les objets. De cette manière, les méthodes peuvent restreindre le nombre d'objets créés et les conditions dans lesquelles ils sont créés (un cas particulier en est le patron singleton présenté dans Thinking in Patterns with Java, téléchargeable à www.BruceEckel.com).

Voici un exemple qui montre les différentes façons dont le clonage peut être implémenté et interdit plus bas dans la hiérarchie :

//: appendixa:CheckCloneable.java
// Vérifie si une référence peut être clonée.

// Ne peut être clonée, car ne redéfinit pas clone() :
class Ordinary {}

// Redéfinit clone, mais n'implémente pas
// Cloneable :
class WrongClone extends Ordinary {
  public Object clone()
      throws CloneNotSupportedException {
    return super.clone(); // Génère une exception
  }
}

// Fait le nécessaire pour le clonage :
class IsCloneable extends Ordinary 
    implements Cloneable {
  public Object clone() 
      throws CloneNotSupportedException {
    return super.clone();
  }
}

// Interdit le clonage en générant une exception :
class NoMore extends IsCloneable {
  public Object clone() 
      throws CloneNotSupportedException {
    throw new CloneNotSupportedException();
  }
}

class TryMore extends NoMore {
  public Object clone() 
      throws CloneNotSupportedException {
    // Appelle NoMore.clone(), génère une excpetion :
    return super.clone();
  }
}

class BackOn extends NoMore {
  private BackOn duplicate(BackOn b) {
    // Crée une copie de b d'une façon ou d'une autre
    // et renvoie cette copie. C'est une copie sans
    // intérêt, juste pour l'exemple :
    return new BackOn();
  }
  public Object clone() {
    // N'appelle pas NoMore.clone() :
    return duplicate(this);
  }
}

// On ne peut dériver cette classe, donc on ne peut
// redéfinir la méthode clone comme dans BackOn:
final class ReallyNoMore extends NoMore {}

public class CheckCloneable {
  static Ordinary tryToClone(Ordinary ord) {
    String id = ord.getClass().getName();
    Ordinary x = null;
    if(ord instanceof Cloneable) {
      try {
        System.out.println("Attempting " + id);
        x = (Ordinary)((IsCloneable)ord).clone();
        System.out.println("Cloned " + id);
      } catch(CloneNotSupportedException e) {
        System.err.println("Could not clone "+id);
      }
    }
    return x;
  }
  public static void main(String[] args) {
    // Transtypage ascendant :
    Ordinary[] ord = { 
      new IsCloneable(),
      new WrongClone(),
      new NoMore(),
      new TryMore(),
      new BackOn(),
      new ReallyNoMore(),
    };
    Ordinary x = new Ordinary();
    // Ceci ne compilera pas, puisque clone()
    // est protected dans Object:
    //! x = (Ordinary)x.clone();
    // tryToClone() vérifie d'abord si
    // une classe implémente Cloneable :
    for(int i = 0; i < ord.length; i++)
      tryToClone(ord[i]);
  }
} ///:~

La première classe, Ordinary, représente le genre de classes que nous avons rencontrées tout au long de ce livre : pas de support du clonage, mais pas de contrôle sur la clonabilité non plus. Mais si on dispose d'une référence sur un objet Ordinary qui peut avoir été transtypé à partir d'une classe dérivée, on ne peut savoir s'il est peut-être cloné ou non.

La classe WrongClone montre une implémentation incorrecte du clonage. Elle redéfinit bien Object.clone() et rend la méthode public, mais elle n'implémente pas Cloneable, donc quand super.clone() est appelée (ce qui revient à un appel à Object.clone()), une exception CloneNotSupportedException est générée et le clonage échoue.

La classe IsCloneable effectue toutes les actions nécessaires au clonage : clone() est redéfinie et Cloneable implémentée. Cependant, cette méthode clone() et plusieurs autres qui suivent dans cet exemple n'interceptent pas CloneNotSupportedException, mais la font suivre à l'appelant, qui doit alors l'envelopper dans un bloc try-catch. Dans les méthodes clone() typiques il faut intercepter CloneNotSupportedException à l'intérieur de clone() plutôt que de la propager. Cependant dans cet exemple, il est plus intéressant de propager les exceptions.

La classe NoMore tente d'interdire le clonage comme les concepteurs de Java pensaient le faire : en générant une exception CloneNotSupportedException dans la méthode clone() de la classe dérivée. La méthode clone() de la classe TryMore appelle super.clone(), ce qui revient à appeler NoMore.clone(), qui génère une exception et empêche donc le clonage.

Mais que se passe-t-il si le programmeur ne respecte pas la chaîne d'appel « recommandée » et n'appelle pas super.clone() à l'intérieur de la méthode clone() redéfinie ? C'est ce qui se passe dans la classe BackOn. Cette classe utilise une méthode séparée duplicate() pour créer une copie de l'objet courant et appelle cette méthode dans clone() au lieu d'appeler super.clone(). L'exception n'est donc jamais générée et la nouvelle classe est cloneable. La seule solution vraiment sûre est montrée dans ReallyNoMore, qui est final et ne peut donc être dérivée. Ce qui signifie que si clone() génère une exception dans la classe final, elle ne peut être modifiée via l'héritage et la prévention du clonage est assurée (on ne peut appeler explicitement Object.clone() depuis une classe qui a un niveau arbitraire d'héritage ; on en est limité à appeler super.clone(), qui a seulement accès à sa classe parente directe). Implémenter des objets qui traitent de sujets relatifs à la sécurité implique donc de rendre ces classes final.

La première méthode qu'on voit dans la classe CheckCloneable est tryToClone(), qui prend n'importe quel objet Ordinary et vérifie s'il est cloneable grâce à instanceof. Si c'est le cas, il transtype l'objet en IsCloneable, appelle clone() et retranstype le résultat en Ordinary, interceptant toutes les exceptions générées. Remarquez l'utilisation de l'identification dynamique du type (voir titre XIV) pour imprimer le nom de la classe afin de suivre le déroulement du programme.

Dans main(), différents types d'objets Ordinary sont créés et transtypés en Ordinary dans la définition du tableau. Les deux premières lignes de code qui suivent créent un objet Ordinary et tentent de le cloner. Cependant ce code ne compile pas, car clone() est une méthode protected dans Object. Le reste du code parcourt le tableau et essaye de cloner chaque objet, reportant le succès ou l'échec de l'opération. Le résultat est :

Attempting IsCloneable
Cloned IsCloneable
Attempting NoMore
Could not clone NoMore
Attempting TryMore
Could not clone TryMore
Attempting BackOn
Cloned BackOn
Attempting ReallyNoMore
Could not clone ReallyNoMore

1. Implémenter l'interface Cloneable.
2. Redéfinir clone().
3. Appeler super.clone() depuis la méthode clone() de la classe.
4. Intercepter les exceptions à l'intérieur de la méthode clone().

Ceci produira l'effet désiré.

XVIII-C-1. Le constructeur de copie▲

//: appendixa:CopyConstructor.java
// Un constructeur pour copier un objet du même
// type, dans une tentative de créer une copie locale.

class FruitQualities {
  private int weight;
  private int color;
  private int firmness;
  private int ripeness;
  private int smell;
  // etc.
  FruitQualities() { // Constucteur par défaut.
    // fait des tas de choses utiles...
  }
  // D'autres constructeurs :
  // ...
  // Constructeur de copie :
  FruitQualities(FruitQualities f) {
    weight = f.weight;
    color = f.color;
    firmness = f.firmness;
    ripeness = f.ripeness;
    smell = f.smell;
    // etc.
  }
}

class Seed {
  // Membres...
  Seed() { /* Constructeur par défaut */ }
  Seed(Seed s) { /* Constructeur de copie */ }
}

class Fruit {
  private FruitQualities fq;
  private int seeds;
  private Seed[] s;
  Fruit(FruitQualities q, int seedCount) { 
    fq = q;
    seeds = seedCount;
    s = new Seed[seeds];
    for(int i = 0; i < seeds; i++)
      s[i] = new Seed();
  }
  // Autres constructeurs :
  // ...
  // Constructeur de copie :
  Fruit(Fruit f) {
    fq = new FruitQualities(f.fq);
    seeds = f.seeds;
    // Appelle le constructeur de copie sur toutes les Seed :
    for(int i = 0; i < seeds; i++)
      s[i] = new Seed(f.s[i]);
    // D'autres activités du constructeur de copie...
  }
  // Pour permettre aux constructeurs dérivés (ou aux
  // autres méthodes) de changer les qualités :
  protected void addQualities(FruitQualities q) {
    fq = q;
  }
  protected FruitQualities getQualities() {
    return fq;
  }
}

class Tomato extends Fruit {
  Tomato() {
    super(new FruitQualities(), 100);
  }
  Tomato(Tomato t) { // Constructeur de copie.
    super(t); // Transtypage pour le constructeur de copie parent.
    // D'autres activités du constructeur de copie...
  }
}

class ZebraQualities extends FruitQualities {
  private int stripedness;
  ZebraQualities() { // Constructeur par défaut.
    // Fait des tas de choses utiles...
  }
  ZebraQualities(ZebraQualities z) {
    super(z);
    stripedness = z.stripedness;
  }
}

class GreenZebra extends Tomato {
  GreenZebra() {
    addQualities(new ZebraQualities());
  }
  GreenZebra(GreenZebra g) {
    super(g); // Appelle Tomato(Tomato)
    // Restitue les bonnes qualités :
    addQualities(new ZebraQualities());
  }
  void evaluate() {
    ZebraQualities zq = 
      (ZebraQualities)getQualities();
    // Utilise les qualités
    // ...
  }
}

public class CopyConstructor {
  public static void ripen(Tomato t) {
    // Utilise le « constructeur de copie » :
    t = new Tomato(t); 
    System.out.println("In ripen, t is a " +
      t.getClass().getName());
  }
  public static void slice(Fruit f) {
    f = new Fruit(f); // Hmmm... est-ce que cela va marcher ?
    System.out.println("In slice, f is a " +
      f.getClass().getName());
  }
  public static void main(String[] args) {
    Tomato tomato = new Tomato();
    ripen(tomato); // OK
    slice(tomato); // OOPS!
    GreenZebra g = new GreenZebra();
    ripen(g); // OOPS!
    slice(g); // OOPS!
    g.evaluate();
  }
} ///:~

t = new Tomato(t);

f = new Fruit(f);

In ripen, t is a Tomato
In slice, f is a Fruit
In ripen, t is a Tomato
In slice, f is a Fruit

Bien que la copie locale produite par clone() donne les résultats escomptés dans les cas appropriés, c'est un exemple où le programmeur (l'auteur de la méthode) est responsable des effets secondaires indésirables de l'aliasing. Que se passe-t-il dans le cas où on construit une bibliothèque tellement générique et utilisée qu'on ne peut supposer qu'elle sera toujours clonée aux bons endroits ? Ou alors, que se passe-t-il si on veut permettre l'aliasing dans un souci d'efficacité - afin de prévenir la duplication inutile d'un objet -, mais qu'on n'en veut pas les effets secondaires négatifs ?

Une solution est de créer des objets immuables appartenant à des classes en lecture seule. On peut définir une classe telle qu'aucune méthode de la classe ne modifie l'état interne de l'objet. Dans une telle classe, l'aliasing n'a aucun impact puisqu'on peut seulement lire son état interne, donc même si plusieurs portions de code utilisent le même objet cela ne pose pas de problèmes.

Par exemple, la bibliothèque standard Java contient des classes name="Index2266">« wrapper »  pour tous les types fondamentaux. Vous avez peut-être déjà découvert que si on veut stocker un int dans un conteneur tel qu'une ArrayList (qui n'accepte que des références sur un Object), on peut insérer l'int dans la classe Integer de la bibliothèque standard :

//: appendixa:ImmutableInteger.java
// La classe Integer ne peut pas être modifiée.
import java.util.*;

public class ImmutableInteger {
  public static void main(String[] args) {
    ArrayList v = new ArrayList();
    for(int i = 0; i < 10; i++) 
      v.add(new Integer(i));
    //, Mais comment changer l'int à
    // l'intérieur de Integer?
  }
} ///:~

La classe Integer (de même que toutes les classes « wrapper » pour les scalaires) implémentent l'immuabilité d'une manière simple : elles ne possèdent pas de méthodes qui permettent de modifier l'objet.

Si on a besoin d'un objet qui contient un scalaire qui peut être modifié, il faut la créer soi-même. Heureusement, ceci se fait facilement :

//: appendixa:MutableInteger.java
// Une classe wrapper modifiable.
import java.util.*;

class IntValue { 
  int n;
  IntValue(int x) { n = x; }
  public String toString() { 
    return Integer.toString(n);
  }
}

public class MutableInteger {
  public static void main(String[] args) {
    ArrayList v = new ArrayList();
    for(int i = 0; i < 10; i++) 
      v.add(new IntValue(i));
    System.out.println(v);
    for(int i = 0; i < v.size(); i++)
      ((IntValue)v.get(i)).n++;
    System.out.println(v);
  }
} ///:~

Notez que n est amical pour simplifier le codage.

IntValue peut même être encore plus simple si l'initialisation à zéro est acceptable (auquel cas on n'a plus besoin du constructeur) et qu'on n'a pas besoin d'imprimer cet objet (auquel cas on n'a pas besoin de toString()) :

class IntValue { int n; }

La recherche de l'élément et son transtypage par la suite est un peu lourd et maladroit, mais c'est une particularité de ArrayList et non de IntValue.

XVIII-D-1. Créer des classes en lecture seule▲

//: appendixa:Immutable1.java
// Des objets qu'on ne peut modifier
// ne craignent pas l'aliasing.

public class Immutable1 {
  private int data;
  public Immutable1(int initVal) {
    data = initVal;
  }
  public int read() { return data; }
  public boolean nonzero() { return data != 0; }
  public Immutable1 quadruple() {
    return new Immutable1(data * 4);
  }
  static void f(Immutable1 i1) {
    Immutable1 quad = i1.quadruple();
    System.out.println("i1 = " + i1.read());
    System.out.println("quad = " + quad.read());
  }
  public static void main(String[] args) {
    Immutable1 x = new Immutable1(47);
    System.out.println("x = " + x.read());
    f(x);
    System.out.println("x = " + x.read());
  }
} ///:~

XVIII-D-2. L'inconvénient de l'immuabilité▲

//: appendixa:Immutable2.java
// Une classe compagnon pour modifier
// des objets immuables.

class Mutable {
  private int data;
  public Mutable(int initVal) {
    data = initVal;
  }
  public Mutable add(int x) { 
    data += x;
    return this;
  }
  public Mutable multiply(int x) {
    data *= x;
    return this;
  }
  public Immutable2 makeImmutable2() {
    return new Immutable2(data);
  }
}

public class Immutable2 {
  private int data;
  public Immutable2(int initVal) {
    data = initVal;
  }
  public int read() { return data; }
  public boolean nonzero() { return data != 0; }
  public Immutable2 add(int x) { 
    return new Immutable2(data + x);
  }
  public Immutable2 multiply(int x) {
    return new Immutable2(data * x);
  }
  public Mutable makeMutable() {
    return new Mutable(data);
  }
  public static Immutable2 modify1(Immutable2 y){
    Immutable2 val = y.add(12);
    val = val.multiply(3);
    val = val.add(11);
    val = val.multiply(2);
    return val;
  }
  // Ceci produit le même résultat :
  public static Immutable2 modify2(Immutable2 y){
    Mutable m = y.makeMutable();
    m.add(12).multiply(3).add(11).multiply(2);
    return m.makeImmutable2();
  }
  public static void main(String[] args) {
    Immutable2 i2 = new Immutable2(47);
    Immutable2 r1 = modify1(i2);
    Immutable2 r2 = modify2(i2);
    System.out.println("i2 = " + i2.read());
    System.out.println("r1 = " + r1.read());
    System.out.println("r2 = " + r2.read());
  }
} ///:~

//: appendixa:Stringer.java 
public class stringer{ 
  disparait static String upcase(string s) { 
  return s.toUpperCase().
}
public static void main(String[] args) { 
  String q = new String('' howdy ''); 
  System.out.println(q) ; // howdy 
  String qq = upcase(qq) ; // HOWDY 
  System.out.println(q) ; //howdy } 
} ///:~

Quand q est passé à upcase() c'est en fait une copie de la référence sur q . L'objet auquel cette référence est connectée reste dans la même localisation physique. Les références sont copiées quand elles sont passées en argument.

En regardant la définition de upcase() , on peut voir que la référence passée en argument porte le nom s , et qu'elle existe seulement pendant que le corps de upcase() est exécuté. Quand up­case() se termine, la référence locale s disparaît. Upcase() renvoie le résultat, qui est la chaîne origi­nale avec tous ses caractères en majuscules. Bien sûr, elle renvoie en fait une référence sur le resul­tat. Mais la référence qu'elle renvoie porte sur un nouvel objet, et l'original q est laissé inchangé.

Comment cela se fait-il ?

Si on écrit :

String s = '' asdf ''; 
String x = Stringer.upcase(s);

Est-ce qu'on veut réellement que la méthode upcase() modifie l'argument ? En général, non, car pour le lecteur du code, un argument est une information fournie à la méthode et non quelque chose qui puisse être modifié. C'est une garantie importante, car elle rend le code plus facile à lire et à comprendre.

En C++, cette garantie a été jugée suffisamment importante pour justifier l'introduction d'un mot-clef special, const , pour permettre au programmeur de s'assurer qu'une référence (pointeur ou référence C++) ne pouvait être utilisée pour modifier l'objet original. Mais le programmeur C++ de­vait alors faire attention et se rappeler d'utiliser const de partout. Cela peut être déroutant et facile à oublier.

Les objets de la classe String sont conçus pour être immuables, en utilisant les techniques montrées précédemment. Lorsqu'on examine la documentation en ligne de la classe String (qui est résumée un peu plus loin dans cette annexe), on se rend compte que chaque méthode de la classe qui semble modifier un objet String crée et renvoie un nouvel objet de la classe contenant la modification ; la String original reste inchangée. Il n'y a donc pas de fonctionnalité en Java telle que le const du C++ pour s'assurer de l'immuabilité des objets lors de la compilation. Si on en a besoin, il faut l'implémenter soi-même, comme le fait la classe String.

Comme les objets String sont immuables, on peut aliasser un objet String autant de fois qu'on veut. Puisqu'il est en lecture seule, une référence ne peut rien modifier qui peut affecter les autres références. Un objet en lecture seule résout donc élégamment le problème de l'aliasing.

Il semble également possible de gérer tous les cas dans lesquels on a besoin de modifier un objet en créant une nouvelle version de l'objet avec les modifications, comme le fait la classe String . Ce n'est toutefois pas efficace pour certaines opérations. C'est le cas de l'opérateur « + » qui a été surchargé pour les objets String . Surchargé veut dire qu'un sens supplémentaire lui a été attribué s'il est utilisé avec une classe particulière (les opérateurs « + » et « += » pour les String sont les seuls opérateurs surchargés en Java, et JAVA ne permet pas au programmeur d'en surcharger d'autre) (67) .

Quand il est utilisé avec des objets String, l'opérateur « + » permet de concaténer des String :

String s = ''abc'' + foo + ''def'' + integer.toString(47);

on peut imaginer comment ceci pourrait être implémenté: la String «  abc » pourrait avoir une méthode append() qui créerait un nouvel objet String contenant la chaîne « abc » concaténée avec le contenu de foo. Le nouvel objet String devrait alors créer une nouvelle String à laquelle serait ajoutée la chaîne « def », et ainsi de suite.

Cela marcherait bien sûr, mais cela nécessiterait la création d'un grand nombre d'objets String rien que pour assembler la nouvelle String et donc on se retrouverait avec un ensemble d'objets String intermédiaires qui devraient être réclamés par le ramasse-miettes. Je suspecte les concepteurs de Java d'avoir tenté cette approche en premier (une leçon de la conception logiciel - on ne sait réellement rien d'un système tant qu'on n'a pas essayé de la coder et qu'on ne dispose pas d'un système fonctionnel). Je suspecte aussi qu'ils ont découvert que les performances étaient inacceptables.

La solution consiste en une classe compagnon modifiable similaire à celle exposée précédemment. Pour la classe String , cette classe compagnon est appelée StringBuffer , et le compilateur crée automatiquement un objet StringBuffer pour évaluer certaines expressions, en particulier quand les opérateurs surchargés « + » et « += » sont utilisés avec des objets String . L'exemple suivant montre ce qui se passe :

//: appendixa: ImmutableStrings.java // 
Démonstration de la classe StringBuffer. 
public class ImmutableStrings { 
public static void main(String[ ] args) { 
String foo = « foo »; 
String s = « abc » + foo + « def » + Integer.toString(47); 
System.out.println(s); 
// L' ''équivalent '' en utilisant la classe StringBuffer : 
StringBuffer 
sb = new StringBuffer(« abc »); //Crée une string! 
sb.append(foo); 
sb.append(« def »); //Crée une String! 
sb.append(Integer.toString(47)); 
System.out.println »sb »; } 
} ///:~

Durant la création de la String s , le compilateur fait à peu près l'équivalent du code suivant qui utilise sb : une StringBuffer est créée et append() est appelée pour ajouter les nouveaux caractères directement dans l'objet StringBuffer (plutôt que de créer de nouvelles copies à chaque fois). Bien que ceci soit beaucoup plus efficace, il est bon de noter que chaque fois qu'on crée une chaîne de caractères quotée telle que « abc » ou « def », le compilateur les transforme en objets String . Il peut donc y avoir plus d'objets créés que ce qu'on pourrait croire, en dépit de l'efficacité permise par la classe StringBuffer .

Voici un aperçu des méthodes disponibles pour les deux classes String et StringBuffer afin de se faire une idée de la manière dont elles interagissent. Ces tables ne référencent pas toutes les méthodes disponibles, mais seulement celles qui sont importantes pour notre sujet. Les méthodes surchargées sont résumées sur une ligne.

On peut voir que chaque méthode de la classe String renvoie un nouvel objet String quand il est nécessaire d'en modifier le contenu. Remarquez aussi que si le contenu n'a pas besoin d'être mo­difié la méthode renverra juste une référence sur la String originale. Cela permet d'économiser sur le stockage et le surcoût d'une création.

Et voici la classe Stringbuffer :

La méthode la plus fréquemment utilisée est append() , qui est utilisée par le compilateur quand il évalue des expressions String contenant les opérateurs « + » et « += ». La méthode insert() a une forme similaire, et les deux méthodes réalisent des modifications significatives sur le buffer au lieu de créer de nouveaux objets.

La classe String n'est donc pas une simple classe dans Java. La classe String est spéciale à bien des égards, en particulier parce que c'est une classe intégrée et fondamentale dans Java. Il y a le fait qu'une chaîne de caractères entre quotes est convertie en String par le compilateur et les opérateurs « + » et « += ». Dans cette annexe vous avez pu voir d'autres spécificités : l'immuabilité pré­cautionneusement assurée par la classe compagnon StringBuffer et d'autres particularités magiques du compilateur.

Puisque dans Java tout est référence, et puisque chaque objet est créé dans le segment et réclamée par le ramasse-miettes seulement quand il n'est plus utilisé, la façon de manipuler les objets change, spécialement lors du passage et du retour d'objets. Par exemple, en C ou en C++, si on veut initialiser un endroit de stockage dans une méthode, il faut demander à l'utilisateur de passer l'adresse de cet endroit de stockage à la méthode, ou alors il faut se mettre d'accord sur qui a la responsabilité de détruire cet espace de stockage. L'interface et la compréhension de telles méthodes sont donc bien plus compliquées. Mais en Java, on n'a pas à se soucier de savoir si un objet existera toujours lorsqu'on en aura besoin, puisque tout est déjà géré pour nous. On peut ne créer un objet que quand on en a besoin, et pas avant, sans se soucier de déléguer les responsabilités sur cet objet : on passe simplement une référence. Quelquefois la simplification que cela engendre passe inaperçue, d'autres fois elle est flagrante.

Les inconvénients de cette magie sous-jacente sont doubles :

1. Il y a toujours une pénalité d'efficacité pour cette gestion supplémentaire de la mémoire (bien qu'elle puisse être relativement faible), et il y a toujours une petite incertitude sur le temps d'exécution (puisque le ramasse-miettes peut être obligé d'entrer en action si la quantité de mémoire disponible n'est pas suffisante). Pour la plupart des applications, les bénéfices compensent largement les inconvénients, et les parties de l'application critiques quant au temps peuvent être écrites en utilisant des méthodes natives (voir annexe B).
2. aliasing : on peut se retrouver accidentellement avec deux références sur le même objet, ce qui est un problème si les deux références sont supposées pointer sur deux objets distincts . Cela demande de faire un peu plus attention, et, si nécessaire, clone() l'objet pour empêcher toute modification intempestive de l'objet par l'autre référence. Cependant on peut supporter l'aliasing pour l'efficacité qu'il procure en évitant cet inconvénient en créant des objets immuables dont les opérations renvoient un nouvel objet du même type ou d'un type différent, mais ne changent pas l'objet original afin que toute référence liée à cet objet ne voie pas de changement.

Certaines personnes insinuent que la conception du clonage a été baclée en Java, et pour ne pas s'embêter avec, implémentent leur propre version du clonage, sans jamais appeler la méthode Object.clone() , éliminant ainsi le besoin d'implémenter Cloneable et d'intercepter l'exception Clo ne otSupportedException . Ceci est certainement une approche raisonnable et comme clone() est très peu implémentée dans la bibliothèque standard Java, elle est aussi relativement sûre. Mais tant qu'on n'appelle pas Object.clone() on n'a pas besoin d'implémenter Cloneable ou d'intercepter l'exception, donc cela semble acceptable aussi.

Les solutions aux exercices sélectionnés peuvent être trouvées dans le document électronique The Thinking in Java Annotated Solution Guide , disponible pour une faible somme sur www.Bru­ceEckel.com .

1. Démontrer un second niveau d'aliasing. Créer une méthode qui crée une référence sur un objet, mais ne modifie pas cet objet. Par contre, la méthode appelle une seconde méthode, lui passant la référence, et cette seconde méthode modifie l'objet.
2. Créer une classe myString contenant un objet String qu'on initialisera dans le constructeur en utilisant l'argument du constructeur. Ajouter une méthode toString() et une méthode concatenate() qui ajoute un objet String à la chaîne interne. Implémenter clone() dans myString . Créer deux méthodes static acceptant chacune une référence myString x comme argument et appelant x.concatenate("test") , mais la seconde méthode appelle clone() d'abord. Tester les deux méthodes et montrer les différents effets.
3. Créer une classe Battery contenant un int qui est un numéro de batterie (comme identifiant unique). La rendre cloneable et lui donner une méthode toString() . Créer maintenant une classe Toy qui contienne un tableau de Battery et une méthode toString() qui affiche toutes les Battery . Écrire une méthode clone() pour la classe Toy qui clone automatiquement tous ses objets Battery . Tester cette méthode en clonant Toy et en affichant le résultat.
4. Changer CheckCloneable.java afin que toutes les méthodes clone() interceptent l'exception CloneNotSupportedException plutôt que de la faire suivre à l'appelant.
5. En utilisant la technique de la classe compagnon modifiable, créer une classe immuable contenant un int , un double et un tableau de char .
6. Modifier Compete.java pour ajouter de nouveaux objets membres aux classes Thing2 et Thing4 , et voyez si vous pouvez déterminer comment le minutage varie avec la complexité - si c'est une simple relation linéaire ou si cela semble plus compliqué.
7. Modifier Compete.java pour ajouter de nouveaux objets membres aux classes Thing2 et Thing4 , et voyez si vous pouvez déterminer comment le minutage varie avec la complexité - si c'est une simple relation linéaire ou si cela semble plus compliqué.
8. Hériter d'une ArrayList et faire que sa méthode clone() réalise une opération de copie profonde.