EXPLO ITATIO N D 'UNE CLASSE

6.1 La clas s e , com m e "com pos ant logicie l"

Jus q u'ici, nous avions re groupé , au sein d'un m ê m e program m e , la définition de la classe et son utilisation. D ans la pratiq ue , il en ira gé né ralem e nt autre m e nt. En e ffe t, dans un souci de ré utilisabilité , la classe sera fournie com m e un com posant séparé com m e pouvait l'ê tre d'ailleurs une fonction C destiné e à ê tre e m ployé e par plusieurs program m es (l'e xe m ple le plus flagrant é tant ce lui des fonctions de la biblioth è q ue standard). Ce la signifie q u'un utilisate ur pote ntie l de ce tte classe disposera :

• d'un m odule obje t résultant de la com pilation de la définition de la classe, • d'un fich ie r e n-tê te conte nant la déclaration (uniq ue m e nt) de la classe.

En gé né ral, le conce pte ur de la classe la com pilera e n utilisant, lui aussi, le fich ie r e n-tê te q u'il sera am e né à fournir à l'utilisate ur. Ce n'est, bie n sûr, pas une nécessité , m ais ce la sim plifie d'éve ntue lles m odifications ulté rie ures de la classe.

Par e xe m ple, le conce pte ur de la classe point du paragraph e 4.2 pourra cré e r le fich ie r e n-tê te suivant :

_______________________________________________________________________________ ______

/* --- Déclaration de la classe point --- */ class point

{ /* déclaration des membres privés */ int x ;

int y ;

/* déclaration des membres publics */ public :

point (int, int) ; // constructeur void deplace (int, int) ;

void affiche () ; } ;

_______________________________________________________________________________ ______

Fich ie r e n-tê te pour la clas s e point

Si ce fich ie r se nom m e point.h24_{, le conce pte ur fabriq ue ra alors un m odule obje t, e n com pilant la définition} de la classe point.

_______________________________________________________________________________ ______

#include <iostream.h> #include "point.h"

/* --- Définition des fonctions membre de la classe point ---- */ point::point (int abs, int ord)

{

x = abs ; y = ord ; }

24 - Le nom du fich ier peut, bien sûr, ê tre ch oisi com m e vous le voulez. L'extension, par contre, est im posée par l'im plém entation. Il peut s'agir de h , de h xx, h pp, ...

V. Clas s e s e t obje ts 69

void point::deplace (int dx, int dy) { x = x + dx ; y = y + dy ;

}

void point::affiche () {

cout << "Je suis en " << x << " " << y << "\n" ; }

_______________________________________________________________________________ ______

Fich ie r à com piler pour obte nir le m odule obje t de la clas s e point25

Pour faire appe l à la classe point au sein d'un program m e , l'utilisate ur procédera alors ainsi :

• il "inclura" la déclaration de la classe point dans le fich ie r source conte nant son program m e par une dire ctive te lle q ue :

#include "point.h"

• il incorpore ra le m odule obje t correspondant, au m om e nt de l'édition de lie ns de son propre program m e . En principe , à ce nive au, la plupart des édite urs de lie ns n'introduise nt q ue les fonctions ré e llem e nt utilisées, de sorte q u'il ne faut pas craindre de pré voir trop de m é th odes pour une classe.

Parfois, on trouve ra plusieurs classes diffé re ntes au sein d'un m ê m e m odule obje t e t d'un m ê m e fich ie r e n- tê te , de façon com parable à ce q ui se passe pour les fonctions de la biblioth è q ue standard26_{. Là e ncore , e n} gé né ral, seules les fonctions ré e llem e nt utilisées seront incorporées à l'édition de lie ns, de sorte q u'il est toujours possible d'effe ctue r des re groupe m e nts de classes possédant q ue lques affinités.

6.2 Prote ction contre le s inclus ions m ultiple s

Plus tard, nous ve rrons q u'il existe diffé re ntes circonstances pouvant am e ne r l'utilisate ur d'une classe à inclure plusieurs fois un m ê m e fich ie r e n-tê te , lors de la com pilation d'un m ê m e fich ie r source (sans m ê m e q u'il n'e n ait conscie nce !). Ce sera notam m e nt le cas dans les situations d'obje ts m e m bre e t de classes dérivées.

D ans ces conditions, on ris q ue d'aboutir à des erre urs de com pilation, liées tout sim plem e nt à la redéfinition de la classe conce rné e .

En gé né ral, on ré glera ce problèm e e n proté ge ant systé m atiq ue m e nt tout fich ie r e n-tê te des inclusions m ultiples par une te ch niq ue de com pilation conditionne lle, com m e dans :

#ifndef POINT_H #define POINT_H

// déclaration de la classe point #endif

Le sym bole défini pour ch aq ue fich ie r e n-tê te sera ch oisi de façon à é vite r tout ris q ue de doublons. Ici, nous avons ch oisi le nom de la classe (e n m ajuscules), suffixé par _H .

25 - Rappelons que la directive #include possè de deux syntaxes différentes, l'une (<...> ) effectuant la rech e rch e dans un répertoire spé cifiq ue (où se trouve nt les fich ie rs en-tê te standard), l'autre ("...") e ffe ctuant la re ch e rch e dans le ré pe rtoire courant ;é ve ntue llem e nt, on pe ut é galem e nt y spécifie r un ré pe rtoire particulie r.

26 - Avec cette différence, toutefois, que, dans ce cas, on n'a pas à spécifier les m odules objets concernés, au m om ent de l'édition de lie ns.

6.3 Cas des m e m bre s donné e s tatiq ue s

Nous avons vu (paragraph e 5.2) q u'un m e m bre donnée statiq ue doit toujours ê tre initialisé explicite m e nt. D è s lors q u'on est am e né à considérer une classe com m e un com posant séparé , le problèm e se pose alors de savoir dans q ue l fich ie r source place r une te lle initialisation : fich ie r e n-tê te , fich ie r dé finition de la classe, fich ie r utilisate ur (dans notre e xe m ple du paragraph e 5.3, ce problèm e ne se posait pas car nous n'avions q u'un seul fich ie r source ).

O n pourrait pe nser q ue le fich ie r e n-tê te est un e xce llent candidat pour ce tte initialisation, dè s lors q u'il est proté gé contre les inclusions m ultiples. En fait, il n'e n est rie n ;e n e ffe t, si l'utilisate ur com pile séparé m e nt plusieurs fich ie rs source utilisant la m ê m e classe, plusieurs em place m e nts seront gé né rés pour le m ê m e m e m bre statiq ue e t, e n principe , l'édition de lie ns déte cte ra ce tte e rre ur.

Com m e par ailleurs il n'est guè re raisonnable de laisser l'utilisate ur initialiser lui-m ê m e un m e m bre statiq ue (sauf situations , on voit q ue :

il est conseillé de prévoir l'initialisation des m em bres donnée statiques dans le fich ier contenant la définition de la classe.

6.4 En cas de m odification d'une clas s e

A priori, lors q u'une classe est considérée com m e un "com posant logicie l", c'est q u'e lle est "au point" e t q ue , par cons é q ue nt, e lle ne devrait plus ê tre m odifié e . Si, m algré tout, une te lle m odification s'avè re né cessaire , il faut e nvisage r de ux situations assez diffé re ntes.

a) La dé claration de s m e m bre s publics n'a pas ch angé

C'est ce q ui se produit lors q u'on se lim ite à des m odifications inte rnes, n'ayant aucune ré pe rcussion sur la m aniè re d'utiliser la classe (son "inte rface " ave c l'e xté rie ur reste la m ê m e ). Il pe ut s'agir de transform ation de structures de données encapsulées (privées), de m odification d'algorith m es de traite m e nt...

D ans ce cas, les program m es utilisant la classe n'ont pas à ê tre m odifiés. Né anm oins, ils doivent ê tre

recom pilés avec le nouveau fich ier en-tê te correspondant27_{. O n procédera e nsuite à une édition de lie ns} e n incorporant le nouve au m odule obje t.

O n voit donc q ue C+ + pe rm e t une m ainte nance facile d'une classe à laq ue lle on souh aite apporte r des m odifications inte rnes (corre ctions d'erreurs, am é lioration des pe rform ances...) n'atte ignant pas la spécification de son inte rface .

b) La dé claration de s m e m bre s publics a ch angé

Ici, il est clair q ue les program m es utilisant la classe ris q ue nt de nécessite r des m odifications. Ce tte situation devra, bie n sûr, ê tre é vitée dans la m esure du possible. Elle doit ê tre considérée com m e une faute de conce ption de la classe. Nous ve rrons d'ailleurs q ue ces problèm es pourront souve nt ê tre résolus par l'e m ploi du m é canism e d'h é ritage q ui pe rm e t d'adapte r une classe sans la re m e ttre e n cause.

27 - Une telle lim itation n'existe pas dans tous les langages de P.O.O. En C+ + , elle se justifie par le besoin qu'a le com pilateur de connaître la taille des obje ts pour leur alloue r un e m place m e nt.

V. Clas s e s e t obje ts 71