Introduction aux objets

OURS BLANC DES CARPATHES

ISIMA ECOLE DOCTORALE SCIENCES FONDAMENTALES 1999

Introduction aux objets

Table des matires

1. PRSENTATION DE LA NOTION D'OBJET 2. LE PRINCIPE D'ENCAPSULATION 3. L'HRITAGE 3.1 EXEMPLE 1 : LES OBJETS GRAPHIQUES 3.2 EXEMPLE 2 MODLISATION D'UN PARC DE VHICULES 3.3 LES CLASSES ABSTRAITES 3.4 LES DIFFICULTS INHRENTES L'UTILISATION DE L'HRITAGE 3.5 L'HRITAGE MULTIPLE 3.6 LES INTERFACES 4. L'AGRGATION 4.1 DFINITION 4.2 L'AGRGATION COMME ALTERNATIVE L'HRITAGE MULTIPLE OU AUX INTERFACES 5. LE POLYMORPHISME 5.1 DFINITION 5.2 LA PUISSANCE DU POLYMORPHISME 5.3 UNE FORME FAIBLE DE POLYMORPHISME : LA SURCHARGE 6. LA RELATION D'ASSOCIATION 7. POUR CONCLURE SUR LE MODLE OBJET 8. GLOSSAIRE

3 5 6 7 10 11 12 14 15 16 16 17 19 19 19 20 20 22 23

Table des illustrations

Figure 1.1 Reprsentation de la classe Vhicule ..........................................................................................................3 Figure 1.2 Instanciation dune classe en deux objets ...................................................................................................4 Figure 3.1 La hirarchie de la classe ObjetGraphique.................................................................................................8 Figure 3.1 Modle dun parc de vhicules .................................................................................................................10 Figure 3.2 Modle du mme parc de vhicules aprs ajout des avions parmi les objets modliser ..........................11 Figure 3.1 Hirarchie contenant une classe inutile ....................................................................................................13 Figure 3.1 Exemple dutilisation de lhritage multiple .............................................................................................14 Figure 3.2 Hritage rptition : D reoit deux copies de sa classe anctre A..........................................................14 Figure 4.1 Exemple dagrgation pour une classe Vhicule .......................................................................................16 Figure 4.1 Modlisations de l'AWACS mettant en oeuvre des interfaces ....................................................................18 Figure 4.2 Modlisations de l'AWACS utilisant de l'agrgation et de lhritage.........................................................18 Figure 6.1 Modlisation du Zoo par agrgation et association ..................................................................................21 Figure 6.2 Autre modlisation du Zoo par agrgation et association .........................................................................22

Programme 3.1 code gnrique de la mthode DplacerVers ................................................................................9 Programme 5.1 Utilisation du polymorphisme sur une collection...............................................................................19 Programme 5.2 Utilisation du polymorphisme dans la mthode Effacer ................................................................20

Introduction aux objets

1. Prsentation de la notion d'objet

Un objet est une entit cohrente rassemblant des donnes et du code travaillant sur ses donnes. Une classe peut tre considre comme un moule partir duquel on peut crer des objets. La notion de classe peut alors tre considre comme une expression de la notion de classe d'quivalence chre aux mathmaticiens. En fait, on considre plus souvent que les classes sont les descriptions des objets (on dit que les classes sont la mta donne des objets), lesquels sont des instances de leur classe. Pourquoi ce vocabulaire ? une classe dcrit la structure interne d'un objet : les donnes qu'il regroupe, les actions qu'il est capable d'assurer sur ses donnes. Un objet est un tat de sa classe. Considrons par exemple la modlisation d'un vhicule telle que prsente par la figure suivante :

Vhicule #NombreDeVhicules : Entier #Marque : Chane #Puissance fiscale : Entier #Vitesse maximale : Entier #VitesseCourante : Entier +Crer un vhicule() +Dtruire un vhicule() +Dmarrer() +Acclerer(Taux : Entier) +Avancer() +Reculer()

Nom de la classe

Description des attributs ou donnes membres

Description des mthodes = code associ au donnes

Figure 1.1 Reprsentation de la classe Vhicule Dans ce modle, un vhicule est reprsent par une chane de caractres (sa marque) et trois entiers : la puissance fiscale, la vitesse maximale et la vitesse courante. Toutes ces donnes sont reprsentatives d'un vhicule particulier, autrement dit, chaque objet vhicule aura sa propre copie de ses donnes : on parle alors d'attribut d'instance. L'opration d'instanciation qui permet de crer un objet partir d'une classe consiste prcisment fournir des valeurs particulires pour chacun des attributs d'instance. Le schma prcdent nous permet de prsenter UML (Unified Modelling language), langage de reprsentation des systmes objet quasi universellement adopt de nos jours. La prsente introduction ne permettra de voir qu'une infime partie d'UML au travers de son schma de reprsentation statique dont le but est de prsenter les diffrentes classes intervenant dans un modle, Introduction aux objets 3

accompagnes de leurs principales relations. Nous voyons donc qu'une classe est reprsente sous forme d'un rectangle lui mme divis en trois volets dans le sens de la hauteur. r Le volet suprieur indique le nom de la classe r Le volet intermdiaire prsente les attributs et leur type sous la forme : identificateurAttribut : identificateurType. r Le volet infrieur prsente les mthodes accompagnes de leur type de retour et de leurs paramtres Le soulignement indique un membre de classe, que ce soit un attribut ou une mthode. Finalement, les rectangles avec un coin repli sont associs aux notes ou commentaires explicatifs. En revanche, considrons l'attribut Nombre de vhicules charg de compter le nombre de vhicules prsents un moment donn dans la classe. Il est incrment par l'opration Crer un vhicule et dcrment par l'opration Dtruire un vhicule. C'est un exemple typique d'attribut partag par l'ensemble des objets d'une mme classe. Il est donc inutile et mme dangereux (penser aux oprations de mise jour) que chaque objet possde sa copie propre de cet attribut, il vaut mieux qu'ils partagent une copie unique situe au niveau de la classe. On parle donc d'attribut de classe. La figure suivante montre l'opration d'instanciation de la classe en 2 objets diffrents :
Classe Instances

Vhicule #NombreDeVhicules : Entier #Marque : Chane #Puissance fiscale : Entier #Vitesse maximale : Entier #VitesseCourante : Entier +Crer un vhicule() +Dtruire un vhicule() +Dmarrer() +Acclerer(Taux : Entier) +Avancer() +Reculer()

Marque="Lotus" PuissanceFiscale=11 VitesseMaximale=230 VitesseCourante=170 Instanciation Marque="Peugeot" PuissanceFiscale=7 VitesseMaximale=150 VitesseCourante=70

Figure 1.2 Instanciation dune classe en deux objets

Introduction aux objets

Le mme raisonnement s'applique directement aux mthodes. En effet, de la mme manire que nous avions tabli une distinction entre attributs d'instance et attributs de classe, nous allons diffrencier mthodes d'instances et mthodes de classe. Prenons par exemple la mthode Dmarrer. Il est clair qu'elle peut s'appliquer individuellement chaque vhicule pris comme entit spare. En outre, cette mthode va clairement utiliser les attributs d'instance de l'objet auquel elle va s'appliquer c'est donc une mthode d'instance. Considrons dsormais le cas de la mthode Crer un vhicule. Son but est de crer un nouveau vhicule, lequel aura, dans un second temps, le loisir de positionner des valeurs initiales dans chacun de ces attributs d'instance. Si nous considrons en dtail le processus permettant de crer un objet, nous nous apercevons que la premire tape consiste allouer de la mmoire pour le nouvel objet. Hors cette tape n'est clairement pas du ressort d'un objet : seule la classe possde suffisamment d'informations pour la mener bien : la cration d'un objet est donc une mthode de classe. Notons galement qu'au cours de cette tape, l'objet recevra des indications additionnelles, telles que, par exemple, une information lui indiquant quelle classe il appartient. En revanche, considrons la phase d'initialisation des attributs. Celle-ci s'applique un objet bien prcis : celui en cours de cration. L'initialisation des attributs est donc une mthode d'instance. Nous aboutissons finalement au constat suivant : la cration d'un nouvel objet est constitue de deux phases :

Une phase du ressort de la classe : allouer de la mmoire pour le nouvel objet et lui fournir un contexte d'excution minimaliste Une phase du ressort de l'objet : initialiser ses attributs d'instance

Si ces deux phases sont clairement spares dans un langage tel que l'objective C, elles ne le sont plus en C++ ou en Java qui agglomrent toute l'opration dans une mthode spciale, ni vraiment mthode d'instance, ni mthode de classe : le constructeur.

2. Le principe d'encapsulation
Sans le savoir, vous avez dj mis le doigt sur l'un des trois grands principes du paradigme objet : l'encapsulation. Ce principe, digne hritier des principes d'abstraction de donnes et d'abstraction procdurale prne les ides suivantes :

Un objet rassemble en lui mme ses donnes (les attributs) et le code capable d'agir dessus (les mthodes) Abstraction de donnes : la structure d'un objet n'est pas visible de l'extrieur, son interface est constitue de messages invocables par un utilisateur. La rception d'un message dclenche l'excution de mthodes. Abstraction procdurale : Du point de vue de l'extrieur (cest--dire en fait du client de lobjet), l'invocation d'un message est une opration atomique. L'utilisateur n'a aucun lment d'information sur la mcanique interne mise 5

Introduction aux objets

en uvre. Par exemple, il ne sait pas si le traitement requis a demand lintervention de plusieurs mthodes ou mme la cration dobjets temporaires etc. Dans les versions canoniques du paradigme objet, les services d'un objet ne sont invocables quau travers de messages, lesquels sont individuellement composs de :

Un nom Une liste de paramtres en entre Une liste de paramtres en sortie

La liste des messages auxquels est capable de rpondre un objet constitue son interface : c'est la partie publique d'un objet. Tout ce qui concerne son implmentation doit rester cach l'utilisateur final : c'est la partie prive de l'objet. Bien entendu, tous les objets d'une mme classe prsentent la mme interface, en revanche deux objets appartenant des classes diffrentes peuvent prsenter la mme interface. D'un certain point de vue, l'interface peut tre vue comme un attribut de classe particulier. En pratique, dans la plupart des langages orients objet modernes, l'interface reprsente la liste des mthodes accessibles l'utilisateur. Il est trs important de cacher les dtails les dtails d'implmentation des objets l'utilisateur. En effet, cela permet de modifier, par exemple la structure de donnes interne d'une classe (remplacer un tableau par une liste chane) sans pour autant entraner de modifications dans le code de lutilisateur, linterface ntant pas atteinte. Autre exemple : considrons une classe modlisant un point en 2 dimensions pour laquelle on fournit deux mthodes renvoyant respectivement l'abscisse et l'ordonne du point. Peu importe l'utilisateur de savoir que le point est stock rellement sous forme cartsienne ou si le concepteur a opt pour la reprsentation polaire ! Tous les langages orients objet n'imposent pas de respecter le principe d'encapsulation. C'est donc au programmeur de veiller personnellement au grain.

3. L'hritage
L'hritage est le second des trois principes fondamentaux du paradigme orient objet. Il est charg de traduire le principe naturel de Gnralisation / Spcialisation. En effet, la plupart des systmes rels se prtent merveille une classification hirarchique des lments qui les composent. La premire ide ce sujet est lie l'entomologie et aux techniques de classification des insectes en fonction de divers critres. Expliquons nous d'abord sur le terme d'hritage. Il est bas sur l'ide qu'un objet spcialis bnficie ou hrite des caractristiques de l'objet le plus gnral auquel il rajoute ses lments propres. En terme de concepts objets cela se traduit de la manire suivante :

On associe une classe au concept le plus gnral, nous l'appellerons classe de base ou classe mre ou super - classe. 6

Introduction aux objets

Pour chaque concept spcialis, on drive une classe du concept de base. La nouvelle classe est dite classe drive ou classe fille ou sous-classe

L'hritage dnotant une relation de gnralisation / spcialisation, on peut traduire toute relation d'hritage par la phrase : La classe drive est une version spcialise de sa classe de base On parle galement de relation est-un pour traduire le principe de gnralisation / spcialisation. Nous prendrons deux exemples classiques :

3.1 Exemple 1 : les objets graphiques

Considrons un ensemble d'objets graphiques. Chaque objet graphique peut tre considr relativement un point de base que nous reprsenterons par ses coordonnes cartsiennes X et Y. On lui associe galement sa Couleur ainsi que l'paisseur du trait. Hormis la cration et la destruction d'objets, nous associons les mthodes suivantes notre objet graphique :

accs en lecture et en criture des attributs affichage effacement dplacement d'un objet.

Nous obtenons alors la reprsentation de la classe ObjetGraphique prsente sur la figure de la page suivante. Rajoutons deux classes spcialises : Ligne et Cercle. Chacune d'entre elles rajoute ses attributs propres : le rayon pour le cercle, la longueur et l'angle pour la ligne. Ainsi, les mthodes Ligne et Cercle disposent de leurs attributs propres qui traduisent leur spcialisation et des attributs de la classe de base qui sont hrits. Les mthodes de la classe de base sont galement hrites. Les classes Ligne et Cercle n'ont pas, par exemple, fournir de code pour la mthode getX charge de renvoyer la valeur de l'attribut X. En revanche, elles sont libres de rajouter les mthodes qui leur sont propres, par exemple, des mthodes pour accder aux attributs supplmentaires. En outre, si vous regardez attentivement le schma, vous verrez galement que Ligne aussi bien que Cercle redfinissent les mthodes Afficher et Effacer : en effet, un cercle ne s'affiche pas de la mme manire qu'une ligne : cest le polymorphisme appliqu aux mthodes Afficher et Effacer dans le cadre des classes Ligne et Cercle. Nous reviendrons plus en dtails sur le principe de polymorphisme, pour lheure il vous suffit de savoir quune mthode (ou une procdure / fonction) peut prendre diffrentes formes.

Introduction aux objets

r Une forme faible : la surcharge qui permet dutiliser le mme nom de mthode / procdure / fonction avec des listes paramtres diffrentes. r La forme forte du polymorphisme qui concerne la redfinition dune mthode dune classe mre par ses classes drives en utilisant la mme signature (mme liste de paramtres et mme type de retour). Il est important de noter que les signatures (liste de paramtre de type de retour) des mthodes Afficher et Effacer sont les mmes aussi bien dans la classe de base que dans les deux classes drives. Cela permet dappeler la mthode de la mme manire sur nimporte quel objet de la hirarchie sans mme savoir quelle classe il appartient rellement ! la puissance du polymorphisme est sans borne .

Afin d'viter de surcharger le schma les paramtres des mthodes Crer ont t omis
ObjetGraphique
#NombreObjetsGraphiques : Entier #Couleur : TypeCouleur #X : Entier #Y : Entier #Epaisseur : Entier +Crer() +Dtruire() +getX() : Entier +getY() : Entier +setX(valeur : Entier) +setY(valeur : Entier) +DeplacerVers(versX : Entier, versY : Entier) +Afficher() +Effacer()

Classe de base : concept gnral

Classes drives : concept spcialis

Ligne #Longueur : Entier #Angle : Rel +Crer() +Detruire() +getLongueur() : Entier +setLongueur(valeur : Entier) +Afficher() +Effacer() Cercle #Rayon : Entier +Crer() +Detruire() +getRayon() : Entier +setRayon(valeur : Entier) +Afficher() +Effacer()

Figure 3.1 La hirarchie de la classe ObjetGraphique

Introduction aux objets

En notation UML, la relation d'hritage est signale par une flche l'extrmit triangulaire et dont la pointe est oriente vers la classe mre. Les mthodes dont le nom est en italique sont abstraites. On en dduit immdiatement que les classes dont le nom est italique sont galement abstraites et ne peuvent donc pas directement produire dinstances. Rappelons galement que les mthodes ou les attributs souligns sont des membres de classe. J'attire votre attention sur le fait que la mthode DplacerVers n'est pas redfinie. En effet, de manire trs littraire, on peut l'implmenter comme suit :
Mthode ObjetGraphique::DplacerVers(positionX : Entier, positionY : Entier) { [objet Effacer] [objet setX : positionX] [objet setY : positionY] [objet Afficher] }

Programme 3.1 code gnrique de la mthode DplacerVers Il est ais de voir que cette implmentation est tout fait correcte du moment que Effacer fait bien appel la mthode Effacer de Ligne lorsque l'on appelle la mthode DplacerVers sur un objet de classe Ligne et rciproquement pour la classe Cercle. Une fois de plus, nous utilisons ici la notion de polymorphisme. En effet, applique un objet de classe Cercle, la mthode DplacerVers appellera Effacer et Afficher de Cercle (on notera Cercle::Afficher et Cercle::Effacer) ; applique un objet de classe Ligne, ce sont les mthodes Ligne::Afficher et Ligne::Effacer qui seront invoques. Cet exemple, aussi simple, soit-il illustre bien les avantages que l'on retire utiliser de l'hritage :

Le code est de taille plus faible car l'on factorise au niveau des classes gnralises les comportements communs toute une hirarchie Au niveau des classes drives, seul le code spcifique reste crire, il est donc inutile de rinventer la roue chaque tape, et le dveloppement est plus rapide Modlisation d'une notion trs naturelle permettant de crer des systmes conceptuellement bien conus. Le mcanisme de polymorphisme fort repose largement sur lhritage comme nous pourrons le voir par la suite. Le code des classes les plus leves dans la hirarchie (les plus gnralistes) est utilis trs souvent et gagne rapidement en fiabilit car il est trs souvent sollicit et donc dbogu rapidement. 9

Introduction aux objets

Si la hirarchie est bien pense, il est ais de rajoute de nouvelles classes en considrant les diffrences de la nouvelle classe par rapport celles dj prsentes dans la hirarchie : on parle de programmation diffrentielle.

3.2 Exemple 2 modlisation d'un parc de vhicules

Cet exemple va nous montrer comme utiliser le principe gnralisation / spcialisation pour construire un systme orient objet fiable. L'entreprise A possde un parc de vhicules regroupant : de

des voitures des camions des hlicoptres des bateaux

Elle souhaite disposer d'un modle permettant de modliser le fonctionnement de son parc. Le but est de crer un systme de classes permettant de factoriser le plus possible les fonctionnalits de chaque type de vhicule. Partant des catgories modliser, il apparat assez vident de driver les classes Voiture et Camion d'une mme classe VhiculeRoulant et de laisser de ct les classes Hlicoptre et les Bateau. En outre, bien que diffrents, tous les vhicules partagent certaines caractristiques de par leur caractre mobile. Ainsi des actions telles que Dmarrer, Acclrer, Ralentir ou Arrter possdent un sens pour chaque type de vhicule. Aussi, toutes nos classes vont partager un anctre commun que nous appellerons Vhicule. Nous obtenons alors le modle suivant :
Vhicule

VhiculeRoulant

Hlicoptre

Bateau

Voiture

Camion

Une hirarchie de classes possible pour la modlisation d'un parc htrogne de vhicules

Figure 3.2 Modle dun parc de vhicules

Introduction aux objets

10

Pour raliser ce modle, nous avons procd par gnralisation : partir de l'ensemble des objets terminaux, nous avons cherch tablir des lments communs permettant de mettre en vidence des classes de gnralisation. Ce procd, dit de Gnralisation, est typique de la construction d'une hirarchie de classes ex-nihilo. Le procd de Spcialisation est lui plus utilis lorsqu'il s'agit de greffer de nouvelles classes dans un systme existant. En effet, si la compagnie fait l'acquisition de quelques avions, il sera toujours possible de crer (par Gnralisation) une classe VhiculeArien dont driveront Avion et Hlicoptre. On obtient alors le modle de la Figure 3.3. Ce genre de classification prend parfois le nom de taxinomie, pour rendre hommage ces prcurseurs : les entomologistes qui cherchaient un moyen cohrent et pratique de classification des divers insectes quils tudiaient. Le principe de gnralisation / spcialisation est particulirement intuitif et puissant car il permet didentifier des comportements similaires le long dun arbre de drivation, chaque sous classe tant mme de choisir entre redfinir ou hriter du comportement de sa classe mre.
Vhicule
Une hirarchie de classes possible pour la modlisation d'un parc htrogne de vhicules aprs ajout des avions

VhiculeRoulant

VhiculeArien

Bateau

Voiture

Camion

Hlicoptre

Avion

Figure 3.3 Modle du mme parc de vhicules aprs ajout des avions parmi les objets modliser

3.3 Les classes abstraites

En lecteurs attentifs, vous aurez sans doute remarqu que les titres des classes Vhicule, VhiculeRoulant et VhiculeArien sont en italique dans la figure prcdente. En sus de rendre le schma agrable l'il, cette prsentation n'a rien d'innocent : cela signifie que ces classes sont abstraites. Introduction aux objets 11

Une classe est dite abstraite si elle ne fournit pas d'implmentation pour certaines de ces mthodes qui sont dites mthodes abstraites. Bien entendu, tant incomplte, une classe abstraite ne peut avoir d'instance. Il appartient donc ces classes drives de dfinir du code pour chacune des mthodes abstraites. On parlera alors de classes concrtes ; les classes concrtes tant les seules mme dtre instancies. Quel est le but des classes abstraites : dfinir un cadre de travail pour les classes drives en proposant un ensemble de mthodes que l'on retrouvera tout au long de l'arborescence. Ce mcanisme est fondamental pour la mise en place du polymorphisme. En outre, si l'on considre la classe Vhicule, il est tout fait naturel qu'elle ne puisse avoir d'instance : un vhicule ne correspond aucun objet concret mais plutt au concept d'un objet capable de dmarrer, ralentir, acclrer ou s'arrter, que ce soit une voiture, un camion ou un avion. Dterminer si une classe sera abstraite ou concrte dpend souvent du cahier des charges du logiciel. Au travers de ltude de celui-ci, il est possible de dterminer quelles sont les classes concrtes : ce sont celles qui possdent des instances. A partir de ces dernires, il est possible, par une dmarche de gnralisation, de trouver les classes abstraites qui permettront de bnficier du polymorphisme.

3.4 Les difficults inhrentes l'utilisation de l'hritage

Nous venons de voir deux modles o la dcomposition tait triviale. Il est souvent beaucoup plus difficile de dterminer la bonne hirarchie. La rgle est simple, comme nous l'exprimions ci-dessus, une relation d'hritage doit pouvoir se traduire par "la classe drive est une forme spcialise de sa classe de base".

3.4.1 Hirarchies trop lourdes

Il faut faire attention ne pas trop alourdir la hirarchie en drivant tour de bras. Considrons par exemple une classe Animal de laquelle on drive deux classes Chien et Chat. Jusqu'ici rien dire, on peut en effet comprendre que les diffrences significatives de comportement des deux races d'animaux justifient l'existence de deux classes diffrentes. En revanche, il serait maladroit de driver de Chien des classes telles que ChienJaune ou ChienNoir sous prtexte que la couleur du pelage est diffrente. En effet, je ne pense pas que la couleur d'un chien soit discriminante quand son comportement : il s'agit de toute vidence d'une simple diffrence de valeur d'un attribut correspondant la couleur. De la mme manire, il faut veiller ne pas insrer trop de classes intermdiaires. La figure de la page suivante illustre un cas typique o une classe intermdiaire ne possdant aucune drivation propre peut tre supprime. En effet, si la classe Base dispose de deux classes filles, la classe Intermdiaire1 ne fait qu'alourdir inutilement la hirarchie. En effet, elle est abstraite (comme en tmoigne son nom en italique) donc elle ne peut pas avoir d'instances et elle n'est drive qu'une seule fois. On pourrait donc la supprimer pour intgrer ces caractristiques dans la classe Intermdiaire2. Cet exemple permet en outre d'ajouter une touche de vocabulaire : on appelle Feuille une classe qui n'a pas de drives. Introduction aux objets 12

Base

Feuille 1

Intermdiaire 1

Intermdiaire 2

Exemple d'une classe intermdiaire superftatoire (Intermdiaire 1)

Feuille 2

Feuille 3

Figure 3.4 Hirarchie contenant une classe inutile

3.4.2 L'hritage de construction

L'hritage de construction est un autre exemple de mauvaise utilisation de l'hritage bannir absolument. En effet il consiste driver une classe en lui ajoutant de nouveaux attributs de manire modifier totalement le concept utilis. Par exemple, cela revient considrer qu'un rectangle est une ligne auquel on a rajout une deuxime dimension. En outre, dans notre dernier cas, il est facile de voir que l'hritage est impropre, car la phrase "Un rectangle est une version spcialise d'une ligne" n'a pas de sens.

3.4.3 Les incohrences conceptuelles

Parfois l'hritage peut conduire des aberrations conceptuelles. Considrons par exemple une classe oiseau pourvue de la mthode Voler. On peut, par exemple driver la classe Pingouin qui sera elle mme pourvue de la mthode Voler, soit par hritage, soit par redfinition alors que chacun sait trs bien que les pingouins ne volent pas mme si, dans ce cas, on peut dire sans crainte "Un pingouin est un oiseau spcialis". Aussi, certains langages proposent de l'hritage slectif : le programmeur est invit spcifier quels attributs et quelles mthodes seront hrites. Hors supprimer la mthode Voler dans la hirarchie de Oiseau n'est pas sans poser de problme. En effet, cela nuit totalement au principe de polymorphisme qui veut qu'une mthode prsente dans la classe de base puisse toujours se retrouver dans les classes drives. Introduction aux objets 13

3.5 L'hritage multiple

L'hritage multiple est une extension au modle d'hritage simple o l'on autorise une classe possder plusieurs classes mres afin de modliser une gnralisation multiple. Par exemple, supposons que lon souhaite ajouter la classe Hovercraft notre modle de parc de vhicules. Un Hovercraft est la fois un bateau et un vhicule terrestre. Aussi, il est possible de le modliser de la manire suivante :
VhiculeRoulant Bateau

Hovercraft

Figure 3.5 Exemple dutilisation de lhritage multiple L'utilisation de l'hritage multiple n'est pas sans poser certains problmes. Par exemple, si les deux classes de base ont des attributs ou des mthodes de mme nom, on se trouve confronts des collisions de nommage qu'il convient de rsoudre. Certains langages prfixent le nom de l'attribut par sa classe d'origine.

Figure 3.6 Hritage rptition : D reoit deux copies de sa classe anctre A Autre problme (illustr par la Figure 3.6) : l'hritage multiple se transforme trs souvent en hritage rptition. Ici la classe D hrite de deux copies de la classe A, une travers la classe B, l'autre travers la classe C. Quelle copie doit tre conserve ? Certains langages (dont le C++) proposent des mcanismes permettant de Introduction aux objets 14

grer cette situation pineuses susceptible d'arriver, par exemple, si toutes les classes drivent d'une mme classe anctre. De nombreuses bibliothques de classes utilisent une classe abstraite de base afin de bnficier de mcanismes polymorphiques. Aussi, lon risque dtre confront au problme de lhritage rptition ds que lon utilise de lhritage multiple. Les interfaces fournies par des langages bannissant lhritage multiple (tels que Objective C ou JAVA) proposent une alternative intressante et particulirement agrable lhritage multiple.

3.6 Les interfaces

Les problmes lis l'hritage multiple ont conduit certains concepteurs de langage le bannir des fonctionnalits proposes. On a mme vu l'apparition d'autres mcanismes, tels que les interfaces. Une interface est semblable une classe sans attribut (mais pouvant contenir des constantes) dont toutes les mthodes sont abstraites. En plus de ses caractristiques d'hritage, une classe implmente une interface si elle propose une implmentation pour chacune des mthodes dcrites en interface. Ce mcanisme est particulirement puissant car il cre des relations fortes entre diffrentes classes implmentant les mmes interfaces sans que ces dernires aient une relation de parent. En particulier, les mthodes dcrites dans les interfaces sont, par dfinition, polymorphes puisqu'elles sont implmentes de faon indpendante dans chaque classe implmentant une mme interface. En outre, chaque classe peut implmenter autant d'interfaces qu'elle le dsire. Ce mcanisme, issu du Smalltalk a t repris par les langages Objective C et Java en particulier. Afin de fixer les ides, considrons, par exemple, un systme d'objets modlisant un sous marin nuclaire dont certaines composantes appartenant des branches hirarchiques doivent pouvoir tre affiches sur un plan. Plutt que de faire driver toutes les classes d'un anctre proposant des mthodes d'affichage ce qui serait conceptuellement mauvais certaines classes n'ayant pas lieu d'tre affiches, il sera prfrable d'adjoindre une interface Affichable celles devant figurer sur le plan. Notons galement que si toutes les classes drivaient d'une classe de base proposant les mthodes de dessin, toutes les classes non graphiques auraient t alourdies de diverses mthodes inutiles. Faire la diffrence entre hritage et utilisation d'interfaces n'est pas toujours ais et dpend du point de vue du concepteur mais galement de lenvironnement du logiciel construire. En effet, considrons nouveau lexemple de lhovercraft. Faut il le faire driver uniquement de MachineRoulante et lui faire implmenter une interface MachineNavigante ou bien raliser lhritage sur Bateau et faire implmenter une interface MachineTerrestre ou encore, crer une nouvelle classe indpendante et lui faire implmenter les deux interfaces. La rponse la question n'est pas si simple. En effet, cela dpend des priorits que l'on souhaite donner dans le modle : le critre le plus prioritaire devant tre le sige de l'hritage. Une fois de plus se pose le problme de la subjectivit de la dcomposition qui dpend fortement de la personnalit du modlisateur et de lenvironnement du logiciel concevoir. Introduction aux objets 15

4. L'agrgation
4.1 Dfinition
L'agrgation est un autre type de relation entre deux classes qui traduit cette fois les relations Est compos de ... ou Possde ou encore a . Par exemple, dans un systme mcanique, on pourrait considrer que la classe Voiture est compose d'une instance de la classe Moteur, quatre instances de la classe Roue et une instance de la classe Chassis. L'instanciation passe ncessairement pas l'utilisation d'attributs qui sont eux mmes des objets ou des pointeurs sur des objets ou mme une instance d'une classe conteneur qui elle ralise effectivement l'agrgation. L'une des caractristiques principale de l'agrgation est sa cardinalit. Considrons par exemple l'agrgation de roues par une voiture. Une voiture possde exactement 4 roues (je laisse la roue de secours et les voitures moisies 3 roues au rencard) et chaque roue ne peut pas tre possde par plus d'une voiture. La cardinalit de l'agrgation est donc de 1 ct agrgateur et de 4 du ct agrg. La figure suivante permettra de fixer les ides :

Moteur

Chassis

Roue

Voiture

Figure 4.1 Exemple dagrgation pour une classe Vhicule La notation UML utilise une flche dont la pointe est un losange pour reprsenter l'agrgation. Le losange est du ct de l'agrgateur (de la classe compose). Les cardinalits sont indiques : r ct du losange pour la cardinalit de l'agrgateur (sur le schma : une roue appartient une seule voiture) r ct du trait pour la cardinalit de l'agrg (sur le schma : une voiture possde exactement 4 roues)

Introduction aux objets

16

4.2 L'agrgation comme alternative l'hritage multiple ou aux interfaces

Il est parfois possible de traduire en termes d'agrgation des notions apparentes l'hritage multiple ou l'utilisation d'interfaces. Considrons un systme militaire regroupant des avions et des radars. Tout d'un coup, on dcide d'adjoindre un AWACS : systme mixte Avion / Radar. Comment modliser la situation ? 1. Hritage multiple : driver la classe AWACS d'Avion et de Radar. 2. Utilisation d'interfaces : 2.1. Driver AWACS d'Avion et lui adjoindre implmente par tous les objets de type Radar une interface Dtecteur

2.2. Driver AWACS de Radar et lui adjoindre une interface MachineVolante implmente par tous les avions du modle 2.3. Crer une classe AWACS indpendante et lui adjoindre les interfaces Dtecteur et MachineVolante 3. Utilisation d'agrgation : 3.1. Driver AWACS d'Avion et lui ajouter un attribut Radar 3.2. Driver AWACS de Radar et lui ajouter un attribut Avion 3.3. Crer une classe AWACS indpendante et lui ajouter deux attributs : un Radar et un Avion 4. ... Ces diffrentes possibilits montrent la fois ltendue exceptionnelle de la richesse expressionnelle de l'objet et ces faiblesses. En effet, si certains modles paraissent intuitivement meilleurs que d'autres, aucun ne ressort franchement du lot comme tant le meilleur. En outre, il tait galement possible d'utiliser en mme temps agrgation et implmentation d'interface l o nous avons choisi hritage et agrgation. En outre, un modlisateur orient Radar prfrera probablement les modles 1, 2.2 et 3.2 alors qu'un constructeur d'avions mettra l'accent sur son produit de prdilection en privilgiant les drivations d'avion 1, 2.1 et 3.1. Les schmas de la page suivante montrent certains des diffrents modles que l'on peut crer. A l'heure actuelle, il n'existe pas de notation clairement dfinie en UML pour reprsenter les interfaces. Aussi, le moyen le plus simple consiste utiliser une classe dclare abstraite (sans attributs !) et dont le nom est prfix du mot Interface.

Introduction aux objets

17

Nous utiliserons une flche semblable celle reprsentant la gnralisation / spcialisation mais accompagne dun trait pointill pour symboliser l'implmentation d'une interface par une classe ; la pointe de la flche tant dirige vers l'interface.

Avion

Radar

Interface Dtecteur

Interface MVolante

AWACS 2.3 AWACS 2.2 AWACS 2.1 AWACS 1 Les flches pointilles dnotent l'implmentation d'une interface par une classe

Figure 4.2 Modlisations de l'AWACS mettant en oeuvre des interfaces

Avion

Radar

AWACS 3.1

AWACS 3.2

AWACS 3.3

Figure 4.3 Modlisations de l'AWACS utilisant de l'agrgation et de lhritage

Introduction aux objets

18

5. Le polymorphisme
5.1 Dfinition
Le polymorphisme est le troisime des trois grands principes sur lequel repose le paradigme objet. C'est assurment son aspect la fois le plus puissant et le plus troublant. Comme son nom l'indique le polymorphisme permet une mthode d'adopter plusieurs formes sur des classes diffrentes. Selon les langages, le polymorphisme pourra s'exprimer sur l'ensemble des classes d'un systme alors que d'autres le confinent aux classes appartenant une mme hirarchie.

5.2 La puissance du polymorphisme

Nous allons dmontrer la puissance du polymorphisme au travers de l'exemple classique des classes d'objets graphiques. Un document dessin peut tre vu comme une collection d'objets graphiques qui va contenir des cercles, des rectangles, des lignes, ou toute autre sorte d'objet graphique qui pourrait driver de la classe ObjetGraphique. Une telle agrgation est rendue possible par la notion de compatibilit descendante des pointeurs. En effet, un pointeur (ou, dans certains langages, une rfrence) sur un objet d'une classe spcialise peut toujours tre affect un pointeur sur un objet d'une classe gnraliste. Si nous voulons dessiner un dessin tout entier, il nous faudra appeler la mthode Afficher pour chacun des objets contenus dans le dessin. Hors, nous avons pris soin de conserver la mme signature pour les diffrentes mthodes Afficher de tous les objets appartenant la hirarchie d'ObjetGraphique : c'est la condition Sine Qua Non de l'utilisation du polymorphisme. En effet, nous pouvons maintenant utiliser un code du style :
Mthode Dessin::Afficher { Pour chaque Objet inclus { [objet Afficher] } }

Programme 5.1 Utilisation du polymorphisme sur une collection Le polymorphisme de la mthode Afficher garantit que la bonne mthode sera appele sur chaque objet. La mcanique interne de ce mcanisme stupfiant repose sur la stratgie de liaison diffre ou Late Binding. Considrons un programme classique, l'adresse d'appel d'une procdure ou d'une fonction est calcule au moment de l'dition de liens et code en dur dans le programme : c'est la liaison initiale (ou Early Binding). Dans le cas de la liaison diffre, l'emplacement de la mthode appeler est situ dans l'objet lui mme. C'est donc l'excution que le programme va tablir l'adresse d'appel. Un autre exemple est celui de la mthode DplacerVers (voir le Programme 3.1) que nous avons explicit ci-dessus. En effet, ce code est valable quelle que soit la classe de l'objet graphique sur lequel on l'applique : un dplacement consiste toujours en un effacement pralable, une modification des coordonnes puis un affichage. Une Introduction aux objets 19

fois encore, ce code fonctionne grce au polymorphisme car il est ncessaire que les bonnes versions de Effacer et Afficher soient appeles. De mme, si l'on considre que l'effacement consiste rafficher un objet dans la couleur du fond, on pourrait dfinir la mthode Effacer comme suit :
Mthode ObjetGraphique::Effacer { [objet setCouleur : couleurFonds] [objet Afficher] }

Programme 5.2 Utilisation du polymorphisme dans la mthode Effacer

5.3 Une forme faible de polymorphisme : la surcharge

La surcharge est un mcanisme frquemment propos par les langages de programmation orients objet et qui permet dassocier au mme nom de mthode / fonction / procdure diffrentes signatures. Par exemple, on pourrait proposer deux signatures diffrentes pour la mthode Afficher : Pas dargument si lon dsire utiliser le priphrique daffichage par dfaut Spcification dun priphrique en argument Ce mcanisme nest quune aide la

6. La relation d'association
Lassociation est la troisime grande forme de relation que nous allons considrer aprs celles dhritage et dagrgation. Si l'hritage ne souffre daucune ambigut car elle traduit la phrase est une forme spcialise de (IS A) . La relation dassociation est elle plus difficile caractriser. En effet, selon les auteurs, elle peut tre Communique avec ou bien Utilise un (USES A). En fait, et dans certains cas, il est mme facile de la confondre avec la relation dagrgation comme nous allons le voir dans lexemple qui suit. Afin de fixe un peu les ides, considrons nouveau l'exemple classique du Zoo. D'un certain point de vue (rappelons au passage que le principe d'abstraction est subjectif et dpend fondamentalement du point de vue du modlisateur), le Zoo est compos de :

Un ensemble de cages Un ensemble d'animaux Un ensemble de gardiens

Ces relations tant, de toute vidence, de l'agrgation !

Introduction aux objets

20

En revanche, un gardien doit s'occuper d'un certain nombre d'animaux (possds, par le Zoo) et nettoyer un certain nombre de cages (possdes par le Zoo). De la mme manire, une cage regroupe certains animaux (possds par le Zoo). Ces dernires relations ne sont pas de l'agrgation (on considre habituellement qu'un mme objet n'est pas agrable par plusieurs) mais plutt des Associations. En fait, on rangera dans l'association tout type de relation un peu flou qui ne sera ni de l'agrgation, ni de l'hritage. On obtient alors le schma de la Figure 6.1. A l'instar de l'agrgation, on dfinit des cardinalits sur la relation d'association ainsi que des rles. Par exemple, si nous considrons la relation entre les classes Cage et Gardien, nous pouvons lire : "Un Gardien nettoie de 0 n Cages / Une cage est nettoye par 1 et un seul gardien" Toutefois, il est souvent difficile de dfinir ce qui est de l'agrgation ou de l'association. Par exemple, un autre modle consisterait considrer que le zoo agrge les gardiens et les cages et que ces dernires agrgent les animaux. Ce cas de figure est prsent sur la Figure 6.2.

Zoo

* Est nettoye par 1 * Contient 1 * * Est contenu n Nettoie

Cage

Gardien

nourrit

Animal

est nourri par

Figure 6.1 Modlisation du Zoo par agrgation et association

Introduction aux objets

21

Zoo

Gardien

1 Nettoie

Est nettoye par 0..n

Cage

Nourit

0..n Est nourri par

Animal
n

Figure 6.2 Autre modlisation du Zoo par agrgation et association

7. Pour conclure sur le modle objet

Nous n'avons montr ici que quelques uns des concepts du modle objet qui est en ralit beaucoup plus vaste. Les relations d'agrgation, association et hritage sont les plus fondamentales. Certains auteurs considrent que l'on peut tout faire partir de ces trois motifs essentiels, certains prconisent d'autres types de relations. Le point essentiel retenir est que la modlisation repose sur le principe d'abstraction qui est fondamentalement subjectif et fortement li au modlisateur et aux objectifs du logiciel que lon cherche concevoir ! Ceci n'est pas limit aux objets, mais tout processus de modlisation mais peut ici peut prendre une ampleur considrable. Afin de terminer sur une note positive, examinons la structure d'un programme construit selon les principes objet : un tel logiciel est une collection d'objets communiquant par messages et en interaction constante. Ceci permet d'introduire un nouveau principe d'abstraction : l'abstraction d'excution. En effet, les objets permettent de masquer l'organisation d'un logiciel. Les diffrents constituants peuvent s'excuter de faon squentielle ou concurrente (avec diverses mthodes de communication et ou synchronisation), tre situs sur une mme machine ou distribus sur un rseau : le logiciel final est toujours vu du point de vue de l'utilisateur comme un objet monolithique !

Introduction aux objets

22

8. Glossaire
Abstraction de donnes Principe considrant que la structure interne des donnes est cache leur utilisateur qui ne connat d'elles que les procdures permettant de les traiter. Du point de vue de la programmation objet, on considrera toujours un objet comme une bote noire que l'on manipule en lui envoyant des messages. Principe considrant que toute action est atomique du point de vue de celui qui la dclenche. En un mot, il n'a aucune ide des mcanismes mis en jeu dans l'implmentation de l'action. Du point de vue de la programmation oriente objet, cela signifie que l'appel d'un message est toujours vu comme atomique. Dans la pratique cela revient masquer l'utilisateur le code d'implmentation des sous programmes qu'il utilise. Composant logiciel dcrivant des objets. On dit que la classe est la mta-donne des objets Voir sous classe Voir sous classe Mthode spciale, mi chemin entre la mthode de classe et la mthode d'instance charge de crer un nouvel objet en mmoire et d'initialiser son tat. L'un des trois principes fondamentaux du paradigme objet. Prne, d'une part le rassemblement des donnes et du code les utilisant dans une entit unique nomme objet, d'autre part, la sparation nette entre la partie publique d'un objet (ou interface) seule connue de l'utilisateur de la partie prive ou implmentation qui doit rester masque. Pour de plus amples explications L'un des trois principes fondamentaux du paradigme objet. Possibilit offerte par les langages orients de dfinir des arborescences de classes traduisant le principe de gnralisation spcialisation. Une relation dhritage peut se traduire par la phrase : La classe drive est une version spcialise de sa classe de base Logiciel orient objet Nouvelle faon de concevoir le logiciel oriente vers les donnes plutt que sur les actions, les donnes ayant une plus longue prennit conceptuelle. Un logiciel est alors vu comme une collection dobjets communiquant par messages. Unique moyen de communication fourni par les objets. Une invocation de message se traduit habituellement par l'activation d'une mthode. D'ailleurs, dans la plupart des langages orients objet modernes, il n'y a pas de distinction entre les notions de message et de mthode Entit fondamentale rassemblant des donnes ainsi que le code oprant sur ces donnes. Un objet communique avec son environnement par messages et rpond aux principes d'abstraction de donnes et d'abstraction procdurale. Un ensemble dobjets prsentant les mmes caractristiques forme une classe. Introduction aux objets 23

Abstraction procdurale

Classe Classe drive Classe fille Constructeur

Encapsulation

Hritage

Message

Objet

Paradigme objet

Nouvelle faon de concevoir le logiciel. L'accent est mis sur les donnes et les actions qu'elles supportent plutt que sur une vision totalement procdurale. Le paradigme objet est bas sur trois principes fondamentaux : l'encapsulation, l'hritage et le polymorphisme. L'un des trois principes fondamentaux du paradigme objet. Facult prsente par certaines mthodes dont le comportement est diffrent (malgr une signature identique) selon l'objet auquel elle s'appliquent. Dans la plupart des langages orients objet, ce comportement n'est disponible que pour des classes appartenant au mme graphe d'hritage. Liste de paramtres mthode / procdure / fonction. et type de retour dune

Polymorphisme

Signature

Sous classe

On dit galement Classe fille, ou classe Drive. Se dit dune classe qui drive dune autre classe (on parle de classe mre ou de super classe). Cest une forme spcialise de sa super classe et ce titre, elle redfinit souvent certaines ce ces mthodes pour les adapter ces fonctions. Voir Hritage. Classe gnrale qui a t drive en une ou plusieurs sous classes. Une super classe dfinit un cadre de travail et propose des mthodes dordre gnral toute une famille. Certaines dentre elles sont destines tre redfinies par les sous classes afin dadapter leur comportement dans une classe spcialise. Une super classe peut mme tre abstraite, cest dire ne pas fournir dimplmentation pour certaines mthodes qui devront alors tre redfinies. Voir Hritage.

Super classe

Introduction aux objets

24