egalement les qualificatifsprivateetprotected qui permettent de restreindre la visibilit´e des m´ethodes ou des champs. Par d´efaut, sans qualificatif, les champs ou m´ethodes seront visibles de toutes les classes du mˆeme paquetage. Il existe certaines m´ethodes particuli`eres ditesconstructeurs(d´ej`a vues au chapitre 3).
4.3 H´ eritage
On va voir dans cette section que la m´ethodologie objet va bien plus loin que cela. L’int´erˆet principal de l’organisation en classes d’objets est de d´efinir et d’utiliser des relations entre ces classes. Il est courant que l’on ait besoin de structures de donn´ees informatiques assez g´en´erales (comme un point dans le plan, dans l’exemple qui suit) et d’autres, un peu raffin´ees (comme les points dans le plan, avec une couleur associ´ee, dans ce qui suit). Le deuxi`eme est une instancedu premier en ce sens que tout point color´e est en particulier un point.
Cette remarque n’est pas du pure esth´etique : ayant programm´e des fonctions agissant sur des points (comme une translation par un vecteur, par la suite), on remarque qu’elles devraient aussi s’appliquer naturellement aux points color´es, sans avoir `a les reprogrammer, source de confusion et d’erreurs. Le m´ecanisme d’h´eritage (de code) est fait pour cela. C’est assez similaire `a l’utilisation de th´eor`emes en math´ematiques sur des structures alg´ebriques que l’on peut voir de diverses mani`eres : un espace vectoriel est en particulier un groupe ab´elien, et on peut utiliser n’importe quel th´eor`eme applicable aux groupes pour en d´eduire quelque chose sur les espaces vectoriels.
Reprenons l’exemple de la classePoint. on l’a d´efinie ainsi que ses m´ethodes, au chapitre 3 :
c l a s s P o i n t {
i n t x , y ; // c o o r d o n n e e s t r a n s l a t i o n (i n t u , i n t v ) {
x = x+u ; y = y+v ; } . . . }
4.3. H ´ERITAGE 71 On veut maintenant des points color´es ; au lieu de red´efinir les m´ethodes, dont translation, qui n’ont pas besoin de la couleur, et qui s’appliquent en quelque sort au Point sous-jacent :
c l a s s C o l o r P o i n t {
i n t x , y ; // c o o r d o n n e e s i n t c o l ; // c o u l e u r
t r a n s l a t i o n (i n t u , i n t v ) { x = x+u ; y = y+v ;
} . . . }
On peut ´ecrire : c l a s s C o l o r P o i n t
extends P o i n t { i n t c o l ; // c o u l e u r
. . . }
Par le mot cl´eextends:class A extends B ... , on dit queAh´eritede B. Cela veut dire qu’un ColorPoint cp aura des champs col (accessible par cp.col), mais aussixety(accessibles parcp.xetcp.y). On aura aussi le fait quetranslations’applique implicitement sur un objet de la classeColorPoint en s’appliquant `a sa«sous-partie»Point.
Cela s’appelle l’h´eritage, et permet une ´economie et une structuration du code meilleure (en Java et Caml, n’existe pas en C «pur»).
Remarque : tous les objets Java h´eritent d’une classe unique :Object.
La structuration par h´eritage se d´ecrit g´en´eralement par des diagrammes de classes, qui sont des graphes d´ecrivant les attributs des classes, et leur re-lation d’h´eritage, comme dans l’exemple ci-dessous pour les classes Point et ColorPoint :
class Point
class ColorPoint
On pourrait imaginer d’h´eriter de plusieurs classes en mˆeme temps, pour pouvoir utiliser des champs et des m´ethodes de diverses classes : cela s’appelle l’h´eritage multiple, et est autoris´e en C++ mais pas en Java. L’h´eritage multiple de code est compliqu´e s´emantiquement, et le choix a ´et´e fait en Java de ne pas l’autoriser, mais d’autoriser l’h´eritage simple de code, et multiple de signatures (voir section 4.5).
Terminons cette section par un r´esum´e du vocabulaire utile :
72 CHAPITRE 4. PROGRAMMATION ORIENT ´EE OBJET, EN JAVA – h´eritage: une classe peut ˆetre unesous-classed’une autre. La sous-classe l’´etenden rajoutant des m´ethodes et des attributs, elle acc`ede aux attributs et aux m´ethodes de sa sur-classe ;
– polymorphisme (par sous-typage) : un objet d’une sous-classe A de B en acc´edant aux m´ethodes de Best consid´er´e du typeB(et A).
En fait, on a aussi une forme de polymorphisme pour les m´ethodes : Prenons l’exemple de deux impl´ementations possible de calcul garanti
(c’est-`
a-dire qui permet de«repr´esenter»fid`element le calcul dans les r´eels, en utili-sant des nombres machine, en pr´ecision finie), l’une par arithm´etique rationnelle :
c l a s s Rat {
L’autre par arithm´etique d’intervalles : c l a s s D o u b l e i n t {
Les m´ethodesplusetshowsontpolymorphes: elles peuvent prendre desRat ou des Doubleint. C’est souvent tr`es pratique, cela permet d’utiliser le mˆeme programme avec des donn´ees de type diff´erent. En voici un exemple d’ex´ecution :
c l a s s Prog {
4.4. EXCEPTIONS 73 }
}
Cela donne : 5/6
[ 0 . 8 3 0 0 0 0 0 0 0 0 0 0 0 0 0 1 , 0 . 8 4 0 0 0 0 0 0 0 0 0 0 0 0 0 1 ]
4.4 Exceptions
Voici un autre trait«moderne»de langages de programmation comme Java (et qui n’existe pas en C par exemple) : les exceptions, pour traiter des cas d’erreur.
Reprenons le code depop()dans la classePile : void pop ( ) {
t h i s. c = t h i s. c . t l ; }
Comment traiter le casthis.c == null? : void pop ( ) {
i f (t h i s. c != n u l l) t h i s. c = t h i s. c . t l ; }
Le probl`eme est que laisserthis.c `anull est trompeur. On pourrait aussi changer le type de la m´ethode pop(). Cette m´ethode pourrait ainsi renvoyer un code d’erreur : int pop()). C’est ce que l’on ferait en C, mais cela n’est pas tr`es satisfaisant. En effet, outre le fait d’avoir `a changer le type de retour des fonctions, ce qui oblige souvent `a changer les types des arguments, pour retourner un r´esultat, par effet de bord sur un argument (pass´e par r´ef´erence).
L’autre probl`eme est qu’il est parfois difficile de traiter l’erreur mˆeme au niveau de l’appelant direct, il est possible qu’une erreur ne soit traitable qu’`a un niveau sup´erieur.
Le bon m´ecanisme qui puisse r´epondre `a ces points est le m´ecanisme d’ex-ceptions. En Java, on les remarque en fait d`es que l’on a une erreur `a l’ex´ecution.
Si l’on fait :
P i l e p = empty ( ) ; p . pop ( ) ;
On obtient :
E x c e p t i o n i n t h r e a d ”main ” j a v a . l a n g . N u l l P o i n t e r E x c e p t i o n a t Prog . pop ( P i l e . j a v a : 1 6 )
a t Prog . main ( P i l e . j a v a : 2 3 )
L’appel du programme a«lev´e une exception», qui aurait pu ˆetre« rattra-p´ee» et trait´ee par l’appelant. Une exception est en quelque sorte le r´esultat d’un comportement erron´e. Ce n’est pas vraiment une erreur au sens classique