Appendix A

A: Passing & Returning Objects
file:///D|/Daniel/TIJ2FR/All/AppendixA.htm
28.04.01 - version 5.4 : - Nettoyage du code html (titres, paragraphes, tableaux, images, ancres) par Armel. 17.07.2000 - version 5.3 : - Corrections apportes par Olivier Thomann. 26.06.2000 - version 5.2 : - Insertion du journal de log. 19.06.2000 - version 5.1 : - Premire publication sur eGroups.
A : Passage & et Retour d'Objets

Vous devriez maintenant tre conscient que lorsque vous passez un objet, vous passez en fait une rfrence sur cet objet.
Presque tous les langages de programmation possdent une faon normale de passer des objets, et la plupart du temps tout se passe bien. Mais il arrive toujours un moment o on doit faire quelque chose d'un peu hors-norme, et alors les choses se compliquent un peu (voire beaucoup dans le cas du C++). Java ne fait pas exception la rgle, et il est important de comprendre exactement les mcanismes du passage d'arguments et de la manipulation des objets passs. Cette annexe fournit des prcisions quant ces mcanismes. Ou si vous prfrez, si vous provenez d'un langage de programmation qui en disposait, cette annexe rpond la question Est-ce que Java utilise des pointeurs ? . Nombreux sont ceux qui ont affirm que les pointeurs sont difficiles manipuler et dangereux, donc proscrire, et qu'en tant que langage propre et pur destin allger le fardeau quotidien de la programmation, Java ne pouvait dcemment contenir de telles choses. Cependant, il serait plus exact de dire que Java dispose de pointeurs ; en fait, chaque identifiant d'objet en Java (les scalaires excepts) est un pointeur, mais leur utilisation est restreinte et surveille non seulement par le compilateur mais aussi par le systme d'excution. Autrement dit, Java utilise les pointeurs, mais pas les pointeurs arithmtiques. C'est ce que j'ai appel les rfrences ; et vous pouvez y penser comme des pointeurs scuriss , un peu comme des ciseaux de cours lmentaire - ils ne sont pas pointus, on ne peut donc se faire mal avec qu'en le cherchant bien, mais ils peuvent tre lents et ennuyeux.
Passage de rfrences
Quand on passe une rfrence une mthode, on pointe toujours sur le mme objet. Un simple test le dmontre :
//: appendixa:PassReferences.java // Le passage de rfrences.
public class PassReferences { static void f(PassReferences h) { System.out.println("h inside f(): " + h);
1 of 44
7/6/01 9:37 AM
} public static void main(String[] args) { PassReferences p = new PassReferences(); System.out.println("p inside main(): " + p); f(p); } } ///:~
La mthode toString() est automatiquement appele dans l'instruction print, dont PassReferences hrite directement de Object comme la mthode toString() n'est pas redfinie. La version toString() de Object est donc utilise, qui affiche la classe de l'objet suivie de l'adresse mmoire o se trouve l'objet (non pas la rfrence, 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 rfrencent bien le mme objet. Ceci est bien plus efficace que de crer un nouvel objet PassReferences juste pour envoyer un argument une mthode. Mais ceci amne une importante question.
Aliasing
L'aliasing veut dire que plusieurs rfrences peuvent tre attaches au mme objet, comme dans l'exemple prcdent. Le problme de l'aliasing survient quand quelqu'un modifie cet objet. Si les propritaires des autres rfrences ne s'attendent pas ce que l'objet change, ils vont avoir des surprises. Ceci peut tre mis en vidence avec un simple exemple :
//: appendixa:Alias1.java // Aliasing : deux rfrences sur un mme 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 rfrence. System.out.println("x: " + x.i); System.out.println("y: " + y.i); System.out.println("Incrementing x");
2 of 44
7/6/01 9:37 AM
x.i++; System.out.println("x: " + x.i); System.out.println("y: " + y.i); } } ///:~
Dans la ligne :
Alias1 y = x; // Assigne la rfrence.
une nouvelle rfrence Alias1 est cre, mais au lieu de se voir assigner un nouvel objet cr avec new, elle reoit une rfrence existante. Le contenu de la rfrence x, qui est l'adresse de l'objet sur lequel pointe x, est assign y ; et donc x et y sont attachs au mme objet. Donc quand on incrmente le i de x dans l'instruction :
x.i++
le i de y sera modifi lui aussi. On peut le vrifier dans la sortie :

x: 7 y: 7 Incrementing x x: 8 y: 8
Une bonne solution dans ce cas est tout simplement de ne pas le faire : ne pas aliaser plus d'une rfrence un mme objet dans la mme porte. Le code en sera d'ailleurs plus simple comprendre et dbugguer. Cependant, quand on passe une rfrence en argument - de la faon dont Java est suppos le faire - l'aliasing entre automatiquement en jeu, et la rfrence locale cre peut modifier l'objet extrieur (l'objet qui a t cr en dehors de la porte de la mthode). En voici un exemple :
//: appendixa:Alias2.java // Les appels de mthodes aliasent implicitement // leurs arguments.
public class Alias2 { int i; Alias2(int ii) { i = ii; } static void f(Alias2 reference) {
3 of 44
7/6/01 9:37 AM
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); } } ///:~
Le rsultat est :
x: 7 Calling f(x) x: 8
La mthode modifie son argument, l'objet extrieur. Dans ce genre de situations, il faut dcider si cela a un sens, si l'utilisateur s'y attend, et si cela peut causer des problmes. En gnral, on appelle une mthode afin de produire une valeur de retour et/ou une modification de l'tat de l'objet sur lequel est appele la mthode (une mthode consiste envoyer un message cet objet). Il est bien moins frquent d'appeler une mthode afin de modifier ses arguments ; on appelle cela appeler une mthode pour ses effets de bord . Une telle mthode qui modifie ses arguments doit tre clairement documente et prvenir propos de ses surprises potentielles. A cause de la confusion et des chausses-trappes engendrs, il vaut mieux s'abstenir de modifier les arguments. S'il y a besoin de modifier un argument durant un appel de mthode sans que cela ne se rpercute sur l'objet extrieur, alors il faut protger cet argument en en crant une copie l'intrieur de la mthode. Cette annexe traite principalement de ce sujet.
Cration de copies locales

En rsum : tous les passages d'arguments en Java se font par rfrence. C'est dire que quand on passe un objet , on ne passe rellement qu'une rfrence un objet qui vit en dehors de la mthode ; et si des modifications sont faites sur cette rfrence, on modifie l'objet extrieur. De plus : l'aliasing survient automatiquement durant le passage d'arguments ; il n'y a pas d'objets locaux, que des rfrences locales ; les rfrences ont une porte, les objets non ; la dure de vie d'un objet n'est jamais un problme 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 prmunir contre les effets ngatifs 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 rfrence. C'est bien, car la manire de faire par dfaut est aussi la plus efficace. Cependant, on peut avoir besoin de traiter l'objet comme s'il tait local afin que les modifications
4 of 44
7/6/01 9:37 AM
apportes n'affectent qu'une copie locale et ne modifient pas l'objet extrieur. De nombreux langages proposent de crer automatiquement une copie locale de l'objet extrieur, l'intrieur de la mthode [79]. Java ne dispose pas de cette fonctionnalit, mais il permet tout de mme de mettre en oeuvre cet effet.
Passage par valeur

Ceci nous amne discuter terminologie, ce qui est toujours bon dans un dbat. Le sens de l'expression passage par valeur dpend de la perception qu'on a du fonctionnement du programme. Le sens gnral est qu'on rcupre une copie locale de ce qu'on passe, mais cela est tempr par notre faon de penser propos de ce qu'on passe. Deux camps bien distincts s'affrontent quant au sens de passage par valeur : 1. Java passe tout par valeur. Quand on passe un scalaire une mthode, on obtient une copie distincte de ce scalaire. Quand on passe une rfrence une mthode, on obtient une copie de la rfrence. Ainsi, tous les passages d'arguments se font par valeur. Bien sr, cela suppose qu'on raisonne en terme de rfrences, mais Java a justement t conu afin de vous permettre d'ignorer (la plupart du temps) que vous travaillez avec une rfrence. C'est dire qu'il permet d'assimiler la rfrence l'objet , car il la drfrence automatiquement lorsqu'on fait un appel une mthode. 2. Java passe les scalaires par valeur (pas de contestations sur ce point), mais les objets sont passs par rfrence. La rfrence est considre comme un alias sur l'objet ; on ne pense donc pas passer une rfrence, mais on se dit plutt je passe l'objet . Comme on n'obtient pas une copie locale de l'objet quand il est pass une mthode, il est clair que les objets ne sont pas passs par valeur. Sun semble plutt soutenir ce point de vue, puisque l'un des mot-clefs rservs mais non implments est byvalue (bien que rien ne prcise si ce mot-clef verra le jour).
Aprs avoir prsent les deux camps et prcis que cela dpend de la faon dont on considre une rfrence , je vais tenter de mettre le problme de ct. En fin de compte, ce n'est pas si important que cela - ce qui est important, c'est de comprendre que passer une rfrence permet de modifier l'objet pass en argument.
Clonage d'objets
La raison la plus courante de crer une copie locale d'un objet est qu'on veut modifier cet objet sans impacter l'objet de l'appelant. Si on dcide de crer une copie locale, la mthode clone() permet de raliser cette opration. C'est une mthode dfinie comme protected dans la classe de base Object, et qu'il faut redfinir comme public dans les classes drives qu'on veut cloner. Par exemple, la classe ArrayList de la bibliothque standard redfinit clone(),on peut donc appeler clone() sur une ArrayList :
//: appendixa:Cloning.java // L'opration clone() ne marche que pour quelques // composants de la bibliothque Java standard. import java.util.*;
class Int { private int i; public Int(int ii) { i = ii; } public void increment() { i++; }
5 of 44
7/6/01 9:37 AM
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(); // Incrmente tous les lments de v2 : for(Iterator e = v2.iterator(); e.hasNext(); ) ((Int)e.next()).increment(); // Vrifie si les lments de v ont t modifis : System.out.println("v: " + v); } } ///:~
La mthode clone() produit un Object, qu'il faut alors retranstyper dans le bon type. Cet exemple montre que la mthode clone() de ArrayList n'essaie pas de cloner chacun des objets que l'ArrayList contient - l'ancienne ArrayList et l'ArrayList clone rfrencent les mmes objets. On appelle souvent cela une copie superficielle, puisque seule est copie la surface d'un objet. L'objet rel est en ralit constitu de cette surface , plus les objets sur lesquels les rfrences pointent, plus tous les objets sur lesquels ces objets pointent, etc... On s'y rfre souvent en parlant de rseau d'objets . On appelle copie profonde le fait de copier la totalit de ce fouillis. On peut voir les effets de la copie superficielle dans la sortie, o les actions ralises sur v2 affectent v :
v: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] v: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
Ne pas essayer d'appeler clone() sur les objets contenus dans l'ArrayList est vraisemblablement une hypothse raisonnable, car rien ne garantit que ces objets sont cloneables [80].
Rendre une classe cloneable

Bien que le mthode clone soit dfinie dans la classe Object, base de toutes les classes, le clonage n'est pas disponible dans toutes les classes [81]. Cela semble contraire l'ide que les mthodes de la classe de base sont
6 of 44
7/6/01 9:37 AM
toujours disponibles dans les classes drives. Le clonage dans Java va contre cette ide ; si on veut le rendre disponible dans une classe, il faut explicitement ajouter du code pour que le clonage fonctionne. Utilisation d'une astuce avec protected Afin d'viter de rendre chaque classe qu'on cre cloneable par dfaut, la mthode clone() est protected dans la classe de base Object. Cela signifie non seulement qu'elle n'est pas disponible par dfaut pour le programmeur client qui ne fait qu'utiliser la classe (sans en hriter), mais cela veut aussi dire qu'on ne peut pas appeler clone() via une rfrence la classe de base (bien que cela puisse tre utile dans certaines situations, comme le clonage polymorphique d'un ensemble d'Objects). C'est donc une manire de signaler, lors de la compilation, que l'objet n'est pas cloneable - et bizarrement, la plupart des classes de la bibliothque standard Java ne le sont pas. Donc, si on crit :
Integer x = new Integer(1); x = x.clone();
On aura un message d'erreur lors de la compilation disant que clone() n'est pas accessible (puisque Integer ne la redfinit pas et qu'elle se rfre donc la version protected). Si, par contre, on se trouve dans une classe drive d'Object (comme le sont toutes les classes), alors on a la permission d'appeler Object.clone() car elle est protected et qu'on est un hritier. La mthode clone() de la classe de base fonctionne - elle duplique effectivement bit bit l'objet de la classe drive, ralisant une opration de clonage classique. Cependant, il faut tout de mme rendre sa propre mthode de clonage public pour la rendre accessible. Donc, les deux points capitaux quand on clone sont : Toujours appeler super.clone() Rendre sa mthode clone public
On voudra probablement redfinir clone() dans de futures classes drives, sans quoi le clone() (maintenant public) de la classe actuelle sera utilis, et pourrait ne pas marcher (cependant, puisque Object.clone() cre une copie de l'objet, a pourrait marcher). L'astuce protected ne marche qu'une fois - la premire fois qu'on cre une classe dont on veut qu'elle soit cloneable hritant d'une classe qui ne l'est pas. Dans chaque classe drive de cette classe la mthode clone() sera accessible puisqu'il n'est pas possible en Java de rduire l'accs une mthode durant la drivation. C'est dire qu'une fois qu'une classe est cloneable, tout ce qui en est driv est cloneable moins d'utiliser les mcanismes (dcrits ci-aprs) pour empcher le clonage. Implmenter l'interface Cloneable Il y a une dernire chose faire pour rendre un objet cloneable : implmenter l'interface Clonable. Cette interface est un peu spciale, car elle est vide !
interface Cloneable {}
La raison d'implmenter cette interface vide n'est videmment pas parce qu'on va surtyper jusqu' Cloneable et appeler une de ses mthodes. L'utilisation d'interface dans ce contexte est considre par certains comme une astuce car on utilise une de ses fonctionnalits dans un but autre que celui auquel on pensait originellement. Implmenter l'interface Cloneable agit comme une sorte de flag, cod en dur dans le type de la classe. L'interface Cloneable existe pour deux raisons. Premirement, on peut avoir une rfrence transtype un type
7 of 44
7/6/01 9:37 AM
de base et ne pas savoir s'il est possible de cloner cet objet. Dans ce cas, on peut utiliser le mot-clef instanceof (dcrit au chapitre 12) pour savoir si la rfrence est connecte un objet qui peut tre clon :
if(myReference instanceof Cloneable) // ...
La deuxime raison en est qu'on ne veut pas forcment que tous les types d'objets soient cloneables. Donc Object.clone() vrifie qu'une classe implmente l'interface Cloneable, et si ce n'est pas le cas, elle gnre une exception CloneNotSupportedException. Donc en gnral, on est forc d'implmenter Cloneable comme partie du mcanisme de clonage.
Pour un clonage russi

Une fois les dtails d'implmentation de clone() compris, il est facile de crer des classes facilement duplicables pour produire des copies locales :
//: appendixa:LocalCopy.java // Crer 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) {
8 of 44
7/6/01 9:37 AM
// Passage par rfrence, modifie l'objet extrieur : 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 rfrences, // 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); } } ///:~
Tout d'abord, clone() doit tre accessible, il faut donc la rendre public. Ensuite, il faut que clone() commence par appeler la version de clone() de la classe de base. La mthode clone() appele ici est celle prdfinie dans Object, et on peut l'appeler car elle est protected et donc accessible depuis les classes drives.
9 of 44
7/6/01 9:37 AM
Object.clone() calcule la taille de l'objet, rserve assez de mmoire pour en crer un nouveau, et copie tous les bits de l'ancien dans le nouveau. On appelle cela une copie bit bit, et c'est typiquement ce qu'on attend d'une mthode clone(). Mais avant que Object.clone() ne ralise ces oprations, elle vrifie d'abord que la classe est Cloneable - c'est dire, si elle implmente l'interface Cloneable. Si ce n'est pas le cas, Object.clone() gnre une exception CloneNotSupportedException pour indiquer qu'on ne peut la cloner. C'est pourquoi il faut entourer l'appel super.clone() dans un bloc try-catch, pour intercepter une exception qui thoriquement ne devrait jamais arriver (parce qu'on a implment l'interface Cloneable). Dans LocalCopy, les deux mthodes g() et f() dmontrent la diffrence entre les deux approches concernant le passage d'arguments. g() montre le passage par rfrence en modifiant l'objet extrieur et en retournant une rfrence cet objet extrieur, tandis que f() clone l'argument, se dtachant de lui et laissant l'objet original inchang. Elle peut alors faire ce qu'elle veut, et mme retourner une rfrence sur ce nouvel objet sans impacter aucunement l'original. noter l'instruction quelque peu curieuse :
v = (MyObject)v.clone();
C'est ici que la copie locale est cre. Afin d'viter la confusion induite par une telle instruction, il faut se rappeler que cet idiome plutt trange est tout fait lgal en Java parce que chaque identifiant d'objet est en fait une rfrence. La rfrence v est donc utilise pour raliser une copie de l'objet qu'il rfrence grce clone(), qui renvoie une rfrence au type de base Object (car c'est ainsi qu'est dfinie Object.clone()) qui doit ensuite tre transtype dans le bon type. Dans main(), la diffrence entre les effets des deux approches de passage d'arguments est teste. La sortie est :
a == b a = 12 b = 12 c != d c = 47 d = 48
Il est important de noter que les tests d'quivalence en Java ne regardent pas l'intrieur des objets compars pour voir si leurs valeurs sont les mmes. Les oprateurs == et != comparent simplement les rfrences. Si les adresses l'intrieur des rfrences sont les mmes, les rfrences pointent sur le mme objet et sont donc gales . Les oprateurs testent donc si les rfrences sont aliases sur le mme objet !
Le mcanisme de Object.clone( )
Que se passe-t-il rellement quand Object.clone() est appel, qui rende si essentiel d'appeler super.clone() quand on redfinit clone() dans une classe ? La mthode clone() dans la classe racine (ie, Object) est charge de la rservation de la mmoire ncessaire au stockage et de la copie bit bit de l'objet original dans le nouvel espace de stockage. C'est dire, elle ne cre pas seulement l'emplacement et copie un Object - elle calcule prcisment la taille de l'objet copi et le duplique. Puisque tout cela se passe dans le code de la mthode clone() dfinie dans la classe de base (qui n'a aucune ide de ce qui est driv partir d'elle), vous pouvez deviner que le processus implique RTTI pour dterminer quel est rellement l'objet clon. De cette faon, la mthode clone() peut rserver la bonne quantit de mmoire et raliser une copie bit bit correcte pour ce type.
10 of 44
7/6/01 9:37 AM
Quoi qu'on fasse, la premire partie du processus de clonage devrait tre un appel super.clone(). Ceci pose les fondations de l'opration de clonage en crant une copie parfaite. On peut alors effectuer les autres oprations ncessaires pour terminer le clonage. Afin de savoir exactement quelles sont ces autres oprations, il faut savoir ce que Object.clone() nous fournit. En particulier, clone-t-il automatiquement la destination de toutes les rfrences ? L'exemple suivant teste cela :
//: appendixa:Snake.java // Teste le clonage pour voir si la destination // des rfrences sont aussi clones.
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) {
11 of 44
7/6/01 9:37 AM
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); } } ///:~
Un Snake est compos d'un ensemble de segments, chacun de type Snake. C'est donc une liste chane simple. Les segments sont crs rcursivement, en dcrmentant le premier argument du constructeur pour chaque segment jusqu' ce qu'on atteigne zro. Afin de donner chaque segment une tiquette unique, le deuxime argument, un char, est incrment pour chaque appel rcursif au constructeur. La mthode increment() incrmente rcursivement chaque tiquette afin de pouvoir observer les modifications, et toString() affiche rcursivement chaque tiquette. La sortie est la suivante :
s = :a:b:c:d:e s2 = :a:b:c:d:e after s.increment, s2 = :a:c:d:e:f
Ceci veut dire que seul le premier segment est dupliqu par Object.clone(), qui ne ralise donc qu'une copie superficielle. Si on veut dupliquer tout le Snake - une copie profonde - il faut raliser d'autres oprations dans la mthode clone() redfinie. Typiquement il faudra donc faire un appel super.clone() dans chaque classe drive d'une classe cloneable pour s'assurer que toutes les oprations de la classe de base (y compris Object.clone()) soient effectues. Puis cela sera suivi par un appel explicite clone() pour chaque rfrence contenue dans l'objet ; sinon ces rfrences seront aliases sur celles de l'objet original. Le mcanisme est le mme que lorsque les constructeurs sont appels - constructeur de la classe de base d'abord, puis constructeur de la classe drive suivante, et ainsi de suite jusqu'au constructeur de la classe drive la plus lointaine de la classe de base. La diffrence est que clone() n'est pas un constructeur, il n'y a donc rien qui permette d'automatiser le processus. Il faut s'assurer de le faire soi-mme.
Cloner un objet compos

Il se pose un problme quand on essaye de faire une copie profonde d'un objet compos. Il faut faire l'hypothse
12 of 44
7/6/01 9:37 AM
que la mthode clone() des objets membres va son tour raliser une copie profonde de leurs rfrences, et ainsi de suite. Il s'agit d'un engagement. Cela veut dire que pour qu'une copie profonde fonctionne il faut soit contrler tout le code dans toutes les classes, soit en savoir suffisamment sur les classes impliques dans la copie profonde pour tre sr qu'elles ralisent leur propre copie profonde correctement. Cet exemple montre ce qu'il faut accomplir pour raliser une copie profonde d'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 {
13 of 44
7/6/01 9:37 AM
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 rfrences : 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);
14 of 44
7/6/01 9:37 AM
// Maintenant on le clone : OceanReading r = (OceanReading)reading.clone(); } } ///:~
DepthReading et TemperatureReading sont quasi identiques ; elles ne contiennent toutes les deux que des scalaires. La mthode clone() est donc relativement simple : elle appelle super.clone() et renvoie le rsultat. Notez que le code de clone() des deux classes est identique. OceanReading est compose d'objets DepthReading et TemperatureReading ; pour raliser une copie profonde, sa mthode clone() doit donc cloner les rfrences l'intrieur de OceanReading. Pour raliser ceci, le rsultat de super.clone() doit tre transtyp dans un objet OceanReading (afin de pouvoir accder aux rfrences depth et temperature).
Copie profonde d'une ArrayList

Reprenons l'exemple ArrayList expos plus tt dans cette annexe. Cette fois-ci la classe Int2 est cloneable, on peut donc raliser une copie profonde de l'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"); }
15 of 44
7/6/01 9:37 AM
return o; } }
// Une fois qu'elle est cloneable, l'hritage // ne supprime pas cette proprit : 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 hrit 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 lment : for(int i = 0; i < v.size(); i++) v2.set(i, ((Int2)v2.get(i)).clone()); // Incrmente tous les lments de v2 : for(Iterator e = v2.iterator(); e.hasNext(); ) ((Int2)e.next()).increment();
16 of 44
7/6/01 9:37 AM
// Vrifie si les lments de v ont t modifis : System.out.println("v: " + v); System.out.println("v2: " + v2); } } ///:~
Int3 est drive de Int2 et un nouveau membre scalaire int j a t ajout. On pourrait croire qu'il faut redfinir clone() pour tre sr que j soit copi, mais ce n'est pas le cas. Lorsque la mthode clone() de Int2 est appele la place de la mthode clone() de Int3, elle appelle Object.clone(), qui dtermine qu'elle travaille avec un Int3 et duplique tous les bits de Int3. Tant qu'on n'ajoute pas de rfrences qui ont besoin d'tre clones, l'appel Object.clone() ralise toutes les oprations ncessaires au clonage, sans se proccuper de la profondeur hirarchique o clone() a t dfinie. Pour raliser une copie profonde d'une ArrayList, il faut donc la cloner, puis la parcourir et cloner chacun des objets points par l'ArrayList. Un mcanisme similaire serait ncessaire pour raliser une copie profonde d'un HashMap. Le reste de l'exemple prouve que le clonage s'est bien pass en montrant qu'une fois clon, un objet peut tre modifi sans que l'objet original n'en soit affect.
Copie profonde via la srialisation

Quand on examine la srialisation d'objets dans Java (prsente au Chapitre 11), on se rend compte qu'un objet srialis puis dsrialis est, en fait, clon. Pourquoi alors ne pas utiliser la srialisation pour raliser une copie profonde ? Voici un exemple qui compare les deux approches en les chronomtrant :
//: 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) {
17 of 44
7/6/01 9:37 AM
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 donne 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();
18 of 44
7/6/01 9:37 AM
ObjectOutputStream o = new ObjectOutputStream(buf); for(int i = 0; i < a.length; i++) o.writeObject(a[i]); // Rcupre 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 - 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 - t1) + " Milliseconds"); } } ///:~
Thing2 et Thing4 contiennent des objets membres afin qu'une copie profonde soit ncessaire. Il est intressant de noter que bien que les classes Serializable soient plus faciles implmenter, elles ncessitent plus de travail pour les copier. Le support du clonage demande plus de travail pour crer la classe, mais la duplication des objets est relativement simple. Les rsultats sont difiants. Voici la sortie obtenue pour trois excutions :
Duplication via serialization: 940 Milliseconds Duplication via cloning: 50 Milliseconds
19 of 44
7/6/01 9:37 AM
Outre la diffrence significative de temps entre la srialisation et le clonage, vous noterez aussi que la srialisation semble beaucoup plus sujette aux variations, tandis que le clonage a tendance tre plus stable.
Supporter le clonage plus bas dans la hirarchie

Si une nouvelle classe est cre, sa classe de base par dfaut est Object, qui par dfaut n'est pas cloneable (comme vous le verrez dans la section suivante). Tant qu'on n'implmente pas explicitement le clonage, celui-ci ne sera pas disponible. Mais on peut le rajouter n'importe quel niveau et la classe sera cloneable partir de ce niveau dans la hirarchie, comme ceci :
//: appendixa:HorrorFlick.java // On peut implmenter le Clonage // n'importe quel niveau de la hirarchie. 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 {
20 of 44
7/6/01 9:37 AM
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(); } } ///:~
Tant que le clonage n'est pas support, le compilateur bloque toute tentative de clonage. Si le clonage est ajout dans la classe Scientist, alors Scientist et tous ses descendants sont cloneables.
Pourquoi cet trange design ?

Si tout ceci vous semble trange, c'est parce que a l'est rellement. On peut se demander comment on en est arriv l. Que se cache-t-il derrire cette conception ? Originellement, Java a t conu pour piloter des botiers, sans aucune pense pour l'Internet. Dans un langage gnrique tel que celui-ci, il semblait sens que le programmeur soit capable de cloner n'importe quel objet. C'est ainsi que clone() a t place dans la classe de base Object, mais c'tait une mthode public afin qu'un objet puisse toujours tre clon. Cela semblait l'approche la plus flexible, et aprs tout, quel mal y avait-il cela ? Puis, quand Java s'est rvl comme le langage de programmation idal pour Internet, les choses ont chang. Subitement, des problmes de scurit sont apparus, et bien sr, ces problmes ont t rgls en utilisant des objets, et on ne voulait pas que n'importe qui soit capable de cloner ces objets de scurit. Ce qu'on voit donc est une suite de patchs appliqus sur l'arrangement initialement simple : clone() est maintenant protected dans Object. Il faut la redfinir et implementer Cloneableet traiter les exceptions. Il est bon de noter qu'on n'est oblig d'utiliser l'interface Cloneable que si on fait un appel la mthode clone() de Object, puisque cette mthode vrifie lors de l'excution que la classe implmente Cloneable. Mais dans un souci de cohrence (et puisque de toute faon Cloneable est vide), il vaut mieux l'implmenter.
Contrler la clonabilit
On pourrait penser que, pour supprimer le support du clonage, il suffit de rendre private la mthode clone(), mais ceci ne marchera pas car on ne peut prendre une mthode de la classe de base et la rendre moins accessible dans une classe drive. Ce n'est donc pas si simple. Et pourtant, il est essentiel d'tre capable de contrler si un objet peut tre clon ou non. Une classe peut adopter plusieurs attitudes ce propos : 1. L'indiffrence. Rien n'est fait pour supporter le clonage, ce qui signifie que la classe ne peut tre clone,
21 of 44
7/6/01 9:37 AM
2.
3.
4.
5.
6.
mais qu'une classe drive peut implmenter le clonage si elle veut. Ceci ne fonctionne que si Object.clone() traite comme il faut tous les champs de la classe. Implmenter clone(). Respecter la marche suivre pour l'implmentation de Cloneable et redfinir clone(). Dans la mthode clone() redfinie, appeler super.clone() et intercepter toutes les exceptions (afin que la mthode clone() redfinie ne gnre pas d'exceptions). Supporter le clonage conditionnellement. Si la classe contient des rfrences sur d'autres objets qui peuvent ou non tre cloneables (une classe conteneur, par exemple), la mthode clone() peut essayer de cloner tous les objets rfrencs, et s'ils gnrent 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 clons. Ne pas implmenter Cloneable mais redfinir clone() en protected, en s'assurant du fonctionnement correct du clonage pour chacun des champs. De cette manire, toute classe drive peut redfinir clone() et appeler super.clone() pour obtenir le comportement attendu lors du clonage. Cette implmentation peut et doit invoquer super.clone() mme si cette mthode attend un objet Cloneable (elle gnre une exception sinon), car personne ne l'invoquera directement sur un objet de la classe. Elle ne sera invoque qu' travers une classe drive, qui, elle, implmente Cloneable si elle veut obtenir le fonctionnement dsir. Tenter de bloquer le clonage en n'implmentant pas Cloneable et en redfinissant clone() afin de gnrer une exception. Ceci ne fonctionne que si toutes les classes drives appellent super.clone() dans leur redfinition de clone(). Autrement, un programmeur est capable de contourner ce mcanisme. Empcher le clonage en rendant la classe final. Si clone() n'a pas t redfinie par l'une des classes parentes, alors elle ne peut plus l'tre. Si elle a dj t redfinie, la redfinir nouveau et gnrer une exception CloneNotSupportedException. Rendre la classe final est la seule faon d'interdire catgoriquement le clonage. De plus, si on manipule des objets de scurit ou dans d'autres situations dans lesquelles on veut contrler le nombre d'objets crs, il faut rendre tous les constructeurs private et fournir une ou plusieurs mthodes spciales pour crer les objets. De cette manire, les mthodes peuvent restreindre le nombre d'objets crs et les conditions dans lesquelles ils sont crs (un cas particulier en est le patron singleton prsent dans Thinking in Patterns with Java, tlchargeable www.BruceEckel.com).
Voici un exemple qui montre les diffrentes faons dont le clonage peut tre implment et interdit plus bas dans la hirarchie :
//: appendixa:CheckCloneable.java // Vrifie si une rfrence peut tre clone.
// Ne peut tre clone car ne redfinit pas clone() : class Ordinary {}
// Redfinit clone, mais n'implmente pas // Cloneable : class WrongClone extends Ordinary { public Object clone()
22 of 44
7/6/01 9:37 AM
throws CloneNotSupportedException { return super.clone(); // Gnre une exception } }
// Fait le ncessaire pour le clonage : class IsCloneable extends Ordinary implements Cloneable { public Object clone() throws CloneNotSupportedException { return super.clone(); } }
// Interdit le clonage en gnrant 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(), gnre une excpetion : return super.clone(); } }
class BackOn extends NoMore { private BackOn duplicate(BackOn b) { // Cre une copie de b d'une faon ou d'une autre // et renvoie cette copie. C'est une copie sans
23 of 44
7/6/01 9:37 AM
// intrt, juste pour l'exemple : return new BackOn(); } public Object clone() { // N'appelle pas NoMore.clone() : return duplicate(this); } }
// On ne peut driver cette classe, donc on ne peut // redfinir la mthode 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(),
24 of 44
7/6/01 9:37 AM
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() vrifie d'abord si // une classe implmente Cloneable : for(int i = 0; i < ord.length; i++) tryToClone(ord[i]); } } ///:~
La premire classe, Ordinary, reprsente le genre de classes que nous avons rencontr tout au long de ce livre : pas de support du clonage, mais pas de contrle sur la clonabilit non plus. Mais si on dispose d'une rfrence sur un objet Ordinary qui peut avoir t transtyp partir d'une classe drive, on ne peut savoir s'il est peut tre clon ou non. La classe WrongClone montre une implmentation incorrecte du clonage. Elle redfinit bien Object.clone() et rend la mthode public, mais elle n'implmente pas Cloneable, donc quand super.clone() est appele (ce qui revient un appel Object.clone()), une exception CloneNotSupportedException est gnre et le clonage choue. La classe IsCloneable effectue toutes les actions ncessaires au clonage : clone() est redfinie et Cloneable implmente. Cependant, cette mthode clone() et plusieurs autres qui suivent dans cet exemple n'interceptent pasCloneNotSupportedException, mais la font suivre l'appelant, qui doit alors l'envelopper dans un bloc try-catch. Dans les mthodes clone() typiques il faut intercepter CloneNotSupportedException l'intrieur de clone() plutt que de la propager. Cependant dans cet exemple, il est plus intressant de propager les exceptions. La classe NoMore tente d'interdire le clonage comme les concepteurs de Java pensaient le faire : en gnrant une exception CloneNotSupportedException dans la mthode clone() de la classe drive. La mthode clone() de la classe TryMore appelle super.clone(), ce qui revient appeler NoMore.clone(), qui gnre une exception et empche donc le clonage. Mais que se passe-t-il si le programmeur ne respecte pas la chane d'appel recommande et n'appelle pas super.clone() l'intrieur de la mthode clone() redfinie ? C'est ce qui se passe dans la classe BackOn. Cette classe utilise une mthode spare duplicate() pour crer une copie de l'objet courant et appelle cette mthode dans clone()au lieu d'appeler super.clone(). L'exception n'est donc jamais gnre et la nouvelle classe est cloneable. La seule solution vraiment sre est montre dans ReallyNoMore, qui est final et ne peut donc tre drive. Ce qui signifie que si clone() gnre une exception dans la classe final, elle ne peut tre modifie via l'hritage et la prvention du clonage est assure (on ne peut appeler explicitement Object.clone() depuis
25 of 44
7/6/01 9:37 AM
une classe qui a un niveau arbitraire d'hritage ; on en est limit appeler super.clone(), qui a seulement accs sa classe parente directe). Implmenter des objets qui traite de sujets relatifs la scurit implique donc de rendre ces classes final. La premire mthode qu'on voit dans la classe CheckCloneable est tryToClone(), qui prend n'importe quel objet Ordinary et vrifie s'il est cloneable grce instanceof. Si c'est le cas, il transtype l'objet en IsCloneable, appelle clone() et retranstype le rsultat en Ordinary, interceptant toutes les exceptions gnres. Remarquez l'utilisation de l'identification dynamique du type (voir Chapitre 12) pour imprimer le nom de la classe afin de suivre le droulement du programme. Dans main(), diffrents types d'objets Ordinary sont crs et transtyps en Ordinary dans la dfinition du tableau. Les deux premires lignes de code qui suivent crent un objet Ordinary et tentent de le cloner. Cependant ce code ne compile pas car clone() est une mthode protected dans Object. Le reste du code parcourt le tableau et essaye de cloner chaque objet, reportant le succs ou l'chec de l'opration. Le rsultat 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
Donc pour rsumer, si on veut qu'une classe soit cloneable, il faut : 1. 2. 3. 4. Implmenter l'interface Cloneable. Redfinir clone(). Appeler super.clone() depuis la mthode clone() de la classe. Intercepter les exceptions l'intrieur de la mthode clone().
Ceci produira l'effet dsir.
Le constructeur de copie
Le clonage peut sembler un processus compliqu mettre en oeuvre. On se dit qu'il doit certainement exister une autre alternative, et souvent on envisage (surtout les programmeurs C++) de crer un constructeur spcial dont le travail est de dupliquer un objet. En C++, on l'appelle le constructeur de copie. Cela semble a priori la solution la plus vidente, mais en fait elle ne fonctionne pas. Voici un exemple.
//: appendixa:CopyConstructor.java
26 of 44
7/6/01 9:37 AM
// Un constructeur pour copier un objet du mme // type, dans une tentaive de crer une copie locale.
class FruitQualities { private int weight; private int color; private int firmness; private int ripeness; private int smell; // etc... FruitQualities() { // Constucteur par dfaut. // 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 dfaut */ } Seed(Seed s) { /* Constructeur de copie */ } }
class Fruit { private FruitQualities fq;
27 of 44
7/6/01 9:37 AM
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 activits du constructeur de copie... } // Pour permettre aux constructeurs drivs (ou aux // autres mthodes) de changer les qualits : protected void addQualities(FruitQualities q) { fq = q; } protected FruitQualities getQualities() { return fq; } }
class Tomato extends Fruit { Tomato() { super(new FruitQualities(), 100); }
28 of 44
7/6/01 9:37 AM
Tomato(Tomato t) { // Constructeur de copie. super(t); // Transtypage pour le constructeur de copie parent. // D'autres activits du constructeur de copie... } }
class ZebraQualities extends FruitQualities { private int stripedness; ZebraQualities() { // Constructeur par dfaut. // 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 qualits : addQualities(new ZebraQualities()); } void evaluate() { ZebraQualities zq = (ZebraQualities)getQualities(); // Utilise les qualits // ... } }
29 of 44
7/6/01 9:37 AM
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(); } } ///:~
Ceci semble un peu trange premire vue. Bien sr, un fruit a des qualits, mais pourquoi ne pas mettre les donnes membres reprsentant ces qualits directement dans la classe Fruit ? Deux raisons cela. La premire est qu'on veut pouvoir facilement insrer ou changer les qualits. Notez que Fruit possde une mthode protected addQualities() qui permet aux classes drives de le faire (on pourrait croire que la dmarche logique serait d'avoir un constructeur protected dans Fruit qui accepte un argument FruitQualities, mais les constructeurs ne sont pas hrits et ne seraient pas disponibles dans les classes drives). En crant une classe spare pour la qualit des fruits, on dispose d'une plus grande flexibilit, incluant la possibilit de changer les qualits d'un objet Fruit pendant sa dure de vie. La deuxime raison pour laquelle on a dcid de crer une classe FruitQualities est dans le cas o on veut ajouter de nouvelles qualits ou en changer le comportement via hritage ou polymorphisme. Notez que pour les GreenZebra (qui sont rellement un type de tomates - j'en ai cultiv et elles sont fabuleuses), le constructeur appelle addQualities() et lui passe un objet ZebraQualities, qui est driv de FruitQualities et peut donc tre attach la rfrence FruitQualities de la classe de base. Bien sr, quand GreenZebra utilise les FruitQualities il doit le transtyper dans le type correct (comme dans evaluate()), mais il sait que le type est toujours ZebraQualities.
30 of 44
7/6/01 9:37 AM
Vous noterez aussi qu'il existe une classe Seed, et qu'un Fruit (qui par dfinition porte ses propres graines) [82]contient un tableau de Seeds. Enfin, vous noterez que chaque classe dispose d'un constructeur de copie, et que chaque constructeur de copie doit s'occuper d'appeler le constructeur de copie de la classe de base et des objets membres pour raliser une copie profonde. Le constructeur de copie est test dans la classe CopyConstructor. La mthode ripen() accepte un argument Tomato et ralise une construction de copie afin de dupliquer l'objet :
t = new Tomato(t);
tandis que slice( ) accepte un objet Fruit plus gnrique et le duplique aussi :
f = new Fruit(f);
Ces deux mthodes sont testes avec diffrents types de Fruit dans main(). Voici la sortie produite :
In ripen, t is a Tomato In slice, f is a Fruit In ripen, t is a Tomato In slice, f is a Fruit
C'est l que le problme survient. Aprs la construction de copie ralise dans slice() sur l'objet Tomato, l'objet rsultant n'est plus un objet Tomato, mais seulement un Fruit. Il a perdu toute sa tomaticit. De mme, quand on prend une GreenZebra, ripen() et slice() la transforment toutes les deux en Tomato et Fruit, respectivement. La technique du constructeur de copie ne fonctionne donc pas en Java pour crer une copie locale d'un objet. Pourquoi cela fonctionne-t-il en C++ et pas en Java ? Le constructeur de copie est un mcanisme fondamental en C++, puisqu'il permet de crer automatiquement une copie locale d'un objet. Mais l'exemple prcdent prouve que cela ne fonctionne pas en Java. Pourquoi ? En Java, toutes les entits manipules sont des rfrences, tandis qu'en C++ on peut manipuler soit des rfrences sur les objets soit les objets directement. C'est le rle du constructeur de copie en C++ : prendre un objet et permettre son passage par valeur, donc dupliquer l'objet. Cela fonctionne donc trs bien en C++, mais il faut garder prsent l'esprit que ce mcanisme est proscrire en Java.
Classes en lecture seule

Bien que la copie locale produite par clone() donne les rsultats escompts dans les cas appropris, c'est un exemple o le programmeur (l'auteur de la mthode) est responsable des effets secondaires indsirables de l'aliasing. Que se passe-t-il dans le cas o on construit une bibliothque tellement gnrique et utilise qu'on ne peut supposer qu'elle sera toujours clone aux bons endroits ? Ou alors, que se passe-t-il si on veut permettre l'aliasing dans un souci d'efficacit - afin de prvenir la duplication inutile d'un objet - mais qu'on n'en veut pas les effets secondaires ngatifs ?
31 of 44
7/6/01 9:37 AM
Une solution est de crer des objets immuables appartenant des classes en lecture seule. On peut dfinir une classe telle qu'aucune mthode 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 mme si plusieurs portions de code utilisent le mme objet cela ne pose pas de problmes. Par exemple, la bibliothque standard Java contient des classes wrapper pour tous les types fondamentaux. Vous avez peut-tre dj dcouvert que si on veut stocker un int dans un conteneur tel qu'une ArrayList (qui n'accepte que des rfrences sur un Object), on peut insrer l'int dans la classe Integer de la bibliothque standard :
//: appendixa:ImmutableInteger.java // La classe Integer ne peut pas tre modifie. 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'intrieur de Integer? } } ///:~
La classe Integer (de mme que toutes les classes wrapper pour les scalaires) implmentent l'immuabilit d'une manire simple : elles ne possdent pas de mthodes qui permettent de modifier l'objet. Si on a besoin d'un objet qui contient un scalaire qui peut tre modifi, il faut la crer soi-mme. 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); }
32 of 44
7/6/01 9:37 AM
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 mme tre encore plus simple si l'initialisation zro 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'lment et son transtypage par la suite est un peu lourd et maladroit, mais c'est une particularit de ArrayList et non de IntValue.
Crer des classes en lecture seule

Il est possible de crer ses propres classes en lecture seule. Voici un exemple :
//: 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; }
33 of 44
7/6/01 9:37 AM
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()); } } ///:~
Toutes les donnes sont private, et aucune mthode public ne modifie les donnes. En effet, la mthode qui semble modifier l'objet, quadruple(), cre en fait un nouvel objet Immutable1 sans modifier l'objet original. La mthode f() accepte un objet Immutable1 et effectue diverses oprations avec, et la sortie de main() dmontre que x ne subit aucun changement. Ainsi, l'objet x peut tre alias autant qu'on le veut sans risque puisque la classe Immutable1 a t conue afin de guarantir que les objets ne puissent tre modifis.
L'inconvnient de l'immuabilit
Crer une classe immuable semble premire vue une solution lgante. Cependant, ds qu'on a besoin de modifier un objet de ce nouveau type, il faut supporter le cot supplmentaire de la cration d'un nouvel objet, ce qui implique aussi un passage plus frquent du ramasse-miettes. Cela n'est pas un problme pour certaines classes, mais cela est trop coteux pour certaines autres (telles que la classes String). La solution est de crer une classe compagnon qui, elle, peut tre modifie. Ainsi, quand on effectue beaucoup de modifications, on peut basculer sur la classe compagnon modifiable et revenir la classe immuable une fois qu'on en a termin.
L'exemple ci-dessus peut tre modifi pour montrer ce mcanisme :

//: appendixa:Immutable2.java // Une classe compagnon pour modifier // des objets immuables.
34 of 44
7/6/01 9:37 AM
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);
35 of 44
7/6/01 9:37 AM
} 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 mme rsultat : 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()); } } ///:~
Immutable2 contient des mthodes qui, comme prcdemment, prservent l'immuabilit des objets en crant de nouveaux objets ds qu'une modification est demande. Ce sont les mthodes add() et multiply(). La classe compagnon est appele Mutable, et possde aussi des mthodes add() et multiply(), mais ces mthodes modifient l'objet Mutable au lieu d'en crer un nouveau. De plus, Mutable possde une mthode qui utilise ses donnes pour crer un objet Immutable2 et vice-versa. Les deux mthodes static modify1() et modify2() montrent deux approches diffrentes pour arriver au mme rsultat. Dans modify1(), tout est ralis dans la classe Immutable2 et donc quatre nouveaux objets Immutable2 sont crs au cours du processus (et chaque fois que val est rassigne, l'instance prcdente est rcupre par le ramasse-miettes). Dans la mthode modify2(), on peut voir que la premire action ralise est de prendre l'objet Immutable2 y et d'en produire une forme Mutable (c'est comme si on appelait clone() vue prcdemment, mais cette fois un diffrent type d'objet est cr). L'objet Mutable est alors utilis pour raliser un grand nombre d'oprations sans ncessiter la cration de nombreux objets. Puis il est retransform en objet Immutable2. On n'a donc cr que
36 of 44
7/6/01 9:37 AM
deux nouveaux objets (l'objet Mutable et le rsultat Immutable2) au lieu de quatre. Cette approche est donc sense quand : 1. On a besoin d'objets immuables et 2. On a souvent besoin de faire beaucoup de modifications sur ces objets ou 3. Il est prohibitif de crer de nouveaux objets immuables.
Chanes immuables
Examinons le code suivant :
//: appendixa:Stringer.java
public class Stringer { 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(q); System.out.println(qq); // HOWDY System.out.println(q); // howdy } } ///:~
Quand q est pass upcase() c'est en fait une copie de la rfrence sur q. L'objet auquel cette rfrence est connecte reste dans la mme localisation physique. Les rfrences sont copies quand elles sont passes en argument. En regardant la dfinition de upcase(), on peut voir que la rfrence passe en argument porte le nom s, et qu'elle existe seulement pendant que le corps de upcase() est excut. Quand upcase() se termine, la rfrence locale s disparat. upcase() renvoie le rsultat, qui est la chane originale avec tous ses caractres en majuscules. Bien sr, elle renvoie en fait une rfrence sur le rsultat. Mais la rfrence qu'elle renvoie porte sur un nouvel objet, et l'original q est laiss inchang. Comment cela se fait-il ? Constantes implicites Si on crit :
37 of 44
7/6/01 9:37 AM
String s = "asdf"; String x = Stringer.upcase(s);
est-ce qu'on veut rellement que la mthode upcase()modifie l'argument ? En gnral, non, car pour le lecteur du code, un argument est une information fournie la mthode 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 guarantie a t juge suffisamment importante pour justifier l'introduction d'un mot-clef spcial, const, pour permettre au programmeur de s'assurer qu'une rfrence (pointeur ou rfrence en C++) ne pouvait tre utilise pour modifier l'objet original. Mais le programmeur C++ devait alors faire attention et se rappeler d'utiliser const de partout. Cela peut tre droutant et facile oublier. Surcharge de l'oprateur + et les StringBuffer Les objets de la classe String sont conus pour tre immuables, en utilisant les techniques montres prcdemment. Lorsqu'on examine la documentation en ligne de la classe String (qui est rsume un peu plus loin dans cette annexe), on se rend compte que chaque mthode de la classe qui semble modifier un objet String cre et renvoie en fait un nouvel objet String contenant la modification ; la String originale reste inchange. 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'implmenter soi-mme, comme le fait la classe String. Comme les objets String sont immuables, on peut aliaser un objet String autant de fois qu'on veut. Puisqu'il est en lecture seule, une rfrence ne peut rien modifier qui puisse affecter les autres rfrences. Un objet en lecture seule rsoud donc lgamment le problme de l'aliasing. Il semble galement possible de grer tous les cas dans lesquels on a besoin de modifier un objet en crant une nouvelle version de l'objet avec les modifications, comme le fait la classe String. Ce n'est toutefois pas efficace pour certaines oprations. C'est le cas de l'oprateur + qui a t surcharg pour les objets String. Surcharg veut dire qu'un sens supplmentaire lui a t attribu s'il est utilis avec une classe particulire (les oprateurs + et += pour les String sont les seuls oprateurs surchargs en Java, et Java ne permet pas au programmeur d'en surcharger d'autres) [83]. Quand il est utilis avec des objets String, l'oprateur + permet de concatner des String :
String s = "abc" + foo + "def" + Integer.toString(47);
On peut imaginer comment ceci pourrait tre implment : la String abc pourrait avoir une mthode append() qui crerait un nouvel objet String contenant la chane abc concatne avec le contenu de foo. Le nouvel objet String devrait alors crer une nouvelle String laquelle serait ajoute la chane def , et ainsi de suite. Cela marcherait bien sr, mais cela ncessiterait la cration 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 intermdiaires qui devraient tre rclams par le ramasse-miettes. Je suspecte les concepteurs de Java d'avoir tent cette approche en premier (une leon de la conception de logiciel - on ne sait rellement rien d'un systme tant qu'on n'a pas essay de le coder et qu'on ne dispose pas d'un systme fonctionnel). Je suspecte aussi qu'ils ont dcouvert que les performances taient inacceptables.
38 of 44
7/6/01 9:37 AM
La solution consiste en une classe compagnon modifiable similaire celle expose prcdemment. Pour la classe String, cette classe compagnon est appele StringBuffer, et le compilateur cre automatiquement un objet StringBuffer pour valuer certaines expressions, en particulier quand les oprateurs surchargs + et += sont utiliss avec des objets String. L'exemple suivant montre ce qui se passe :
//: appendixa:ImmutableStrings.java // Dmonstration 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"); // Cre une String! sb.append(foo); sb.append("def"); // Cre une String! sb.append(Integer.toString(47)); System.out.println(sb); } } ///:~
Durant la cration de la String s, le compilateur fait peu prs l'quivalent du code suivant qui utilise sb : une StringBuffer est cre et append() est appele pour ajouter les nouveaux caractres directement dans l'objet StringBuffer (plutt que de crer de nouvelles copies chaque fois). Bien que ceci soit beaucoup plus efficace, il est bon de noter que chaque fois qu'on cre une chane de caractres quote telle que abc ou def , le compilateur les transforme en objets String. Il peut donc y avoir plus d'objets crs que ce qu'on pourrait croire, en dpit de l'efficacit permise par la classe StringBuffer.
Les classes String et StringBuffer

Voici un aperu des mthodes disponibles pour les deux classes String et StringBuffer afin de se faire une ide de la manire dont elles interagissent. Ces tables ne rfrencent pas toutes les mthodes disponibles, mais seulement celles qui sont importantes pour notre sujet. Les mthodes surcharges sont rsumes sur une ligne.
Mthode Constructeur
Arguments, Surcharges
Utilisation
Surchargs : Dfaut, String, Cration d'objets String. StringBuffer, tableau de char, tableau
39 of 44
7/6/01 9:37 AM
de byte. length() charAt() getChars(), getBytes() int Index Nombre de caractres dans la String. Le n-ime caractre dans la String. Le dbut et la fin de la zone copier, le Copie des chars ou des bytes dans un tableau dans lequel effectuer la copie, tableau externe. un index dans le tableau destination. Produit un char[] contenant les caractres de la String. Une String avec laquelle comparer. Une String avec laquelle comparer. Un test d'galit sur le contenu de deux String. Le rsultat est ngatif, zro ou positif suivant la comparaison lexicographique de la String et l'argument. Majuscules et minuscules sont diffrencies !
toCharArray() equals(), equals-IgnoreCase() compareTo()
regionMatches()
Dplacement dans la String, une autre Rsultat boolean indiquant si les String ainsi que son dplacement et la rgions correspondent. longueur comparer. Surcharg : ajoute l'insensibilisation la casse. La String avec laquelle la String Rsultat boolean indiquant si la String pourrait dbuter. Surcharg : ajoute un dbute avec l'argument. dplacement pour l'argument. La String qui pourrait tre un suffixe de cette String. Surchargs : char, char et index de dpart, String, String, et index de dpart. Rsultat boolean indiquant si l'argument est un suffixe de la String. Renvoie -1 si l'argument n'est pas trouv dans la String, sinon renvoie l'index o l'argument commence. lastIndexOf() recherche en partant de la fin. Renvoie un nouvel objet String contenant l'ensemble des caractres spcifis. Renvoie un nouvel objet String contenant les caractres de l'objet String intial suivis des caractres de l'argument. Renvoie un nouvel objet String avec les remplacements effectus. Utilise l'ancienne String si aucune corrrespondance n'est trouve. Renvoie un nouvel objet String avec la casse de tous les caractres modifie. Utilise l'ancienne String si aucun changement n'a t effectu. Renvoie un nouvel objet String avec les espaces enlevs chaque extrmit. Utilise l'ancienne String si aucun
startsWith()
endsWith() indexOf(), lastIndexOf()
substring()
Surcharg : index de dpart, index de dpart et index de fin. La String concatner.
concat()
replace()
L'ancien caractre rechercher, le nouveau caractre avec lequel le remplacer.
toLowerCase(), toUpperCase()
trim()
40 of 44
7/6/01 9:37 AM
changement n'a t effectu. valueOf() Surchargs : Object, char[], char[] et Renvoie une String contenant une dplacement et compte, boolean, char, reprsentation sous forme de chane de l'argument. int, long, float, double. Produit une et une seule rfrence String pour chaque squence unique de caractres.
intern()
On peut voir que chaque mthode de la classe String renvoie un nouvel objet String quand il est ncessaire d'en modifier le contenu. Remarquez aussi que si le contenu n'a pas besoin d'tre modifi la mthode renverra juste une rfrence sur la String originale. Cela permet d'conomiser sur le stockage et le surcot d'une cration. Et voici la classe StringBuffer :
Mthode Constructeur toString() length() capacity()
Arguments, Surcharges Surchargs : dfaut, longueur du buffer crer, String partir de laquelle crer.
Utilisation Cre un nouvel objet StringBuffer. Cre un objet String partir de l'objet StringBuffer. Nombre de caractres dans l'objet StringBuffer. Renvoie l'espace actuellement allou. Fait que l'objet StringBuffer alloue au minimum un certain espace.
ensure-Capacity() Entier indiquant la capacit dsire. setLength()
Entier indiquant la nouvelle longueur de la Tronque ou accrot la chane de caractres. Si chane de caractres dans le buffer. accroissement, complte avec des caractres nulls. Entier indiquant la localisation de l'lement Renvoie le char l'endroit spcifi dans le dsir. buffer. Entier indiquant la localisation de l'lment Modifie la valeur un endroit prcis. dsir et la nouvelle valeur char de cet lment. Le dbut et la fin partir de laquelle copier, Copie des chars dans un tableau extrieur. Il le tableau dans lequel copier, un index dans n'existe pas de getBytes() comme dans la le tableau de destination. classe String. Surchargs : Object, String, char[], char[] L'argument est converti en chane de caractres et concatn la fin du buffer avec dplacement et longueur, boolean, courant, en augmentant la taille du buffer si char, int, long, float, double. ncessaire. Surchargs, chacun avec un premier argument contenant le dplacement auquel on dbute l'insertion : Object, String, char[], boolean, char, int, long, float, double. Le deuxime argument est converti en chane de caractres et insr dans le buffer courant au dplacement spcifi. La taille du buffer est augmente si ncessaire. L'ordre des caractres du buffer est invers.
charAt() setCharAt()
getChars()
append()
insert()
reverse()
41 of 44
7/6/01 9:37 AM
()
La mthode la plus frquemment utilise est append(), qui est utilise par le compilateur quand il value des expressions String contenant les oprateurs + et += . La mthodeinsert() a une forme similaire, et les deux mthodes ralisent des modifications significatives sur le buffer au lieu de crer de nouveaux objets.
Les Strings sont spciales

La classe String n'est donc pas une simple classe dans Java. La classe String est spciale bien des gards, en particulier parce que c'est une classe intgre et fondamentale dans Java. Il y a aussi le fait qu'une chane de caractres entre quotes est convertie en String par le compilateur et les oprateurs + et +=. Dans cette annexe vous avez pu voir d'autres spcificits : l'immuabilit prcautionneusement assure par la classe compagnon StringBuffer et d'autres particularits magiques du compilateur.
Rsum
Puisque dans Java tout est rfrence, et puisque chaque objet est cr dans le segment et rclame par le ramasse-miettes seulement quand il n'est plus utilis, la faon de manipuler les objets change, spcialement 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 mthode, il faut demander l'utilisateur de passer l'adresse de cet endroit de stockage la mthode, ou alors il faut se mettre d'accord sur qui a la responsabilit de dtruire cet espace de stockage. L'interface et la comprhension de telles mthodes sont donc bien plus compliques. Mais en Java, on n'a pas se soucier de savoir si un objet existera toujours lorsqu'on en aura besoin, puisque tout est dj gr pour nous. On peut ne crer un objet que quand on en a besoin, et pas avant, sans se soucier de dlguer les responsabilits sur cet objet : on passe simplement une rfrence. Quelquefois la simplification que cela engendre passe inaperue, d'autres fois elle est flagrante. Les inconvnients de cette magie sous-jacente sont doubles : 1. Il y a toujours une pnalit d'efficacit engendre pour cette gestion supplmentaire de la mmoire (bien qu'elle puisse tre relativement faible), et il y a toujours une petite incertitude sur le temps d'excution (puisque le ramasse-miettes peut tre oblig d'entrer en action si la quantit de mmoire disponible n'est pas suffisante). Pour la plupart des applications, les bnfices compensent largement les inconvnients, et les parties de l'application critiques quant au temps peuvent tre crites en utilisant des mthodes native (voir l'annexe B). 2. Aliasing : on peut se retrouver accidentellement avec deux rfrences sur le mme objet, ce qui est un problme si les deux rfrences sont supposes pointer sur deux objets distincts. Cela demande de faire un peu plus attention, et, si ncessaire, clone() l'objet pour empcher toute modification intempestive de l'objet par l'autre rfrence. Cependant on peut supporter l'aliasing pour l'efficacit qu'il procure en vitant cet inconvnient en crant des objets immuables dont les oprations renvoient un nouvel objet du mme type ou d'un type diffrent, mais ne changent pas l'objet original afin que toute rfrence lie cet objet ne voie pas de changements. Certaines personnes insinuent que la conception du clonage a t bacle en Java, et pour ne pas s'embter avec, implmentent leur propre version du clonage [84], sans jamais appeler la mthode Object.clone(), liminant ainsi le besoin d'implmenter Cloneable et d'intercepter l'exception CloneNotSupportedException. Ceci est certainement une approche raisonnable et comme clone() est trs peu implmente dans la bibliothque standard Java, elle est aussi relativement sre. Mais tant qu'on n'appelle pas Object.clone() on n'a pas besoin d'implmenter Cloneable ou d'intercepter l'exception, donc cela semble acceptable aussi.
42 of 44
7/6/01 9:37 AM
Exercises
Les solutions aux exercices slectionns peuvent tre trouves dans le document lectronique The Thinking in Java Annotated Solution Guide, disponible pour une faible somme sur www.BruceEckel.com. 1. Dmontrer un second niveau d'aliasing. Crer une mthode qui cre une rfrence sur un objet mais ne modifie pas cet objet. Par contre, la mthode appelle une seconde mthode, lui passant la rfrence, et cette seconde mthode modifie l'objet. 2. Crer une classe myString contenant un objet String qu'on initialisera dans le constructeur en utilisant l'argument du constructeur. Ajouter une mthode toString() et une mthode concatenate() qui ajoute un objet String la chane interne. Implmenter clone() dans myString. Crer deux mthodes static acceptant chacune une rfrence myString x comme argument et appellant x.concatenate("test"), mais la seconde mthode appelle clone() d'abord. Tester les deux mthodes et montrer les diffrents effets. 3. Crer une classe Battery contenant un int qui est un numro de batterie (comme identifiant unique). La rendre cloneable et lui donner une mthode toString(). Crer maintenant une classe Toy qui contienne un tableau de Battery et une mthode toString() qui affiche toutes les Battery. Ecrire une mthode clone() pour la classe Toy qui clone automatiquement tous ses objets Battery. Tester cette mthode en clonant Toy et en affichant le rsultat. 4. Changer CheckCloneable.java afin que toutes les mthodes clone() interceptent l'exception CloneNotSupportedException plutt que de la faire suivre l'appelant. 5. En utilisant la technique de la classe compagnon modifiable, crer 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 dterminer comment le minutage varie avec la complexit - si c'est une simple relation linaire ou si cela semble plus compliqu. 7. En reprenant Snake.java, crer une version du serpent qui supporte la copie profonde. 8. Hriter d'une ArrayList et faire que sa mthode clone() ralise une opration de copie profonde.
[79]En C, qui gnralement gre des donnes de petite taille, le passage d'arguments par dfaut se fait par valeur. C++ a d suivre cette norme, mais avec les objets, le passage par valeur n'est pas la faon de faire la plus efficace. De plus, coder une classer afin qu'elle supporte le passage par valeur en C++ est un gros casse-tte. [80]Ce n'est pas l'orthographe correcte du mot clonable (N.d.T. : en franais comme en anglais), mais c'est de cette manire qu'il est
utilis dans la bibliothque Java ; j'ai donc dcid de l'utiliser ainsi ici aussi, dans l'espoir de rduire la confusion.
[81]On peut apparemment crer un simple contre-exemple de cette affirmation, comme ceci :
public class Cloneit implements Cloneable { public static void main (String[] args) throws CloneNotSupportedException { Cloneit a = new Cloneit(); Cloneit b = (Cloneit)a.clone(); } } Toutefois, ceci ne marche que parce que main( ) est une mthode de Cloneit et donc a la permission d'appeler la mthode protected
43 of 44
7/6/01 9:37 AM
clone() de la classe de base. Si on l'appelle depuis une autre classe, la compilation gnrera des erreurs.
[82]L'avocat except, qui a t reclassifi en aliment gras . [83]C++ permet au programmeur de surcharger les oprateurs comme il l'entend. Comme ceci se rvle souvent tre un processus
compliqu (voir le Chapitre 10 de Thinking in C++, 2 nd edition, Prentice-Hall, 2000), les concepteurs de Java ont jug une telle fonctionnalit non souhaitable qui ne devait pas donc pas tre intgre dans Java. Elle n'tait apparemment pas si indsirable que cela, puisqu'eux-mmes l'ont finalement utilise, et ironiquement, la surcharge d'oprateurs devrait tre bien plus facile utiliser en Java qu'en C++. On peut le voir dans Python (voir www.python.org) qui dispose d'un ramasse-miettes et d'un mcanisme de surcharge d'oprateurs trs simple mettre en oeuvre.
[84]Doug Lea, qui m'a t d'une aide prcieuse sur ce sujet, m'a suggr ceci, me disant qu'il crait simplement une fonction duplicate() pour chaque classe.
44 of 44
7/6/01 9:37 AM

Appendix A

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Appendix A

Transféré par

Droits d'auteur :

Formats disponibles

A: Passing & Returning Objects

A : Passage & et Retour d'Objets

A: Passing & Returning Objects

A: Passing & Returning Objects

x.i++; System.out.println("x: " + x.i); System.out.println("y: " + y.i); } } ///:~

le i de y sera modifi lui aussi. On peut le vrifier dans la sortie :

A: Passing & Returning Objects

Cration de copies locales

A: Passing & Returning Objects

Passage par valeur

A: Passing & Returning Objects

public String toString() { return Integer.toString(i); } }

Rendre une classe cloneable

A: Passing & Returning Objects

A: Passing & Returning Objects

Pour un clonage russi

public class LocalCopy { static MyObject g(MyObject v) {

A: Passing & Returning Objects

A: Passing & Returning Objects

A: Passing & Returning Objects

A: Passing & Returning Objects

Cloner un objet compos

A: Passing & Returning Objects

A: Passing & Returning Objects

o = super.clone(); } catch(CloneNotSupportedException e) { e.printStackTrace(System.err); } return o; } }

A: Passing & Returning Objects

// Maintenant on le clone : OceanReading r = (OceanReading)reading.clone(); } } ///:~

Copie profonde d'une ArrayList

A: Passing & Returning Objects

A: Passing & Returning Objects

Copie profonde via la srialisation

A: Passing & Returning Objects

System.err.println("Thing3 can't clone"); } return o; } }

A: Passing & Returning Objects

A: Passing & Returning Objects

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

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

Supporter le clonage plus bas dans la hirarchie

public class HorrorFlick {

A: Passing & Returning Objects

Pourquoi cet trange design ?

A: Passing & Returning Objects

// Ne peut tre clone car ne redfinit pas clone() : class Ordinary {}

A: Passing & Returning Objects

throws CloneNotSupportedException { return super.clone(); // Gnre une exception } }

A: Passing & Returning Objects

A: Passing & Returning Objects

A: Passing & Returning Objects

Ceci produira l'effet dsir.

A: Passing & Returning Objects

class Fruit { private FruitQualities fq;

A: Passing & Returning Objects

class Tomato extends Fruit { Tomato() { super(new FruitQualities(), 100); }

A: Passing & Returning Objects

A: Passing & Returning Objects

A: Passing & Returning Objects

Classes en lecture seule

A: Passing & Returning Objects

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

A: Passing & Returning Objects

Crer des classes en lecture seule

A: Passing & Returning Objects

L'exemple ci-dessus peut tre modifi pour montrer ce mcanisme :

A: Passing & Returning Objects