Conception Orientée Objet

IUT Léonard de Vinci, Reims Dpt Info, Y.Remion

ConceptionOrientée

Objet

classes, patrons,

héritage, polymorphisme

Conception Orientée Objet, 2 IUT Léonard de Vinci, Reims Dpt Info, Y.Remion

But du cours

Concepts de la

Conception Orientée Objet

de nouveaux types de données


Plan du cours

Classe

Héritage

Polymorphisme


Chapitre I

Classe

Conception Objet de types structurés

concepts

méthodologie

patron


PolymorphismeHéritageClasseconceptsméthodologiepatron

exemples

Rationnel { Z num, N den }

Client { CHC nom, N noclient, ... }

numRatio

nnel

den

Z

N

...

nom

Client

noclient

CHC

N

Type structuré (programmation classique)

juxtaposition de « données membres » ou « champs »


PolymorphismeHéritageClasse

Un type structuré permet une gestion globale (donc simplifiée) des données

F(C nouv Client) res nouv ClientDébut Allouer Client A,B…Fin,Eliminer A,B,C

F(nomC nouv CHC, noclientC nouv N) ???Début Allouer CHC nomA, nomB N noclientA,noclientB…Fin,Eliminer nomA, noclientA, nomB, noclientB, nomC, noclientC

conceptsméthodologiepatron



Chaque objet dispose de ses propres données membres

Accès au champ x d’un objet O

O.x

...

...

...

CC.nom

C.noclient

F(C nouv Client) res nouv ClientDébut Allouer Client A,B … … A.nom == C.nom … … A.noclient = … …Fin,Eliminer A,B,C

AA.nom

A.noclient

BB.nom

B.noclient




Allouer Client A

naissance des champs

construire (A,…)

...

Réservé

...015849

"Durand"

Réservé

A A

Allocation globaleintégrant automatiquement

les champs

doit construire tous les champsresponsabilité concepteur



mort des champs

Rendre A, Oublier Adétruire (A)

...015849

"Durand"

Réservé

A

...015849

"Durand"

Réservé

A

Libération globaleintégrant automatiquement

les champs

doit détruire tous les champsautomatique en POO

explicite en COO



Classe (programmation OO)

type structuré

+ fonctions associées : « méthodes »

+ variables globales associées : « champs statiques »

+ « encapsulation » : mécanismes de restriction

d’accès aux champs et aux méthodes


Types plus cohérents et plus surs :

outils adaptés

champs et méthodes sensibles protégés



Encapsulation

Accès aux données (consultation et mise à jour) et aux méthodes (possibilité de lancement) par :

toute fonction « accès public »méthodes de la classe seulement « accès privé»

Amitié :La classe peut déclarer son amitié à une classe ou à

une fonction.

Les fonctions amies ou méthodes de classes amies ont les mêmes accès à la classe que ses propres méthodes.



La conception d’une classe fournit 2 documents :

Le document de conception détaillée où figurent tous les champs même privés et les algorithmes de toutes les méthodes

La fiche de description fonctionnelle qui résume et liste les champs et méthodes accessibles en public.

Résultats de la conception d’une classe



Développement d’une classe simple :

Analyse

Réflexions sur le rôle et les constituants de la classe

liste des champs (type, nom, rôle, accès)

liste des méthodes (prototype, sémantique, accès)

Conception détaillée de la classe

Définition algorithmique de la classe

rédaction du document de conception détaillée

Rédaction de la Fiche de Description fonctionnelle

Méthodologie globale de conception



L’analyse d’une classe simple se conduit comme suit:

Identification du rôle de la classe

liste des champs nécessaires et propriétés imposées

fonctions obligatoires ; sémantique et accèsconstructeur/copie , destructeur, réaffecteur

fonctions habituelles ; présence, sémantique, accèsconstructeur/défaut, écrire, saisir

autres fonctions ; prototype, sémantique et accès

analyseconception détaillée

Analyse


Réponse à la question :

« Que représente un objet de ce type ? »


Rôle de la classe

Exemple à suivre ; classe Ratio :

ces objets représentent les nombres rationnels




Champs & Propriétés

Exemple classe Ratio :champs : un numérateur Z num

un dénominateur N den

propriétés imposées :représentation irréductible, dénominateur non nul

accès privé à num et den


Liste des champs (y compris statiques)

avec type, nom, rôle et accès

Propriétés imposées aux champs



Fonctions obligatoires


Ces fonctions qui doivent exister pour tout type T ont généralement sur les classes un comportement classique

constructeur/copie : construction/copie champ à champ

destructeur : destruction des champs

réaffecteur : réaffectation champ à champ




« Cette classe établit-elledirectement des connexionsà des ressources extérieures

à l’objet ? »

Comportements standardsaccès public

Comportements spécifiqueset accès à définir

« Les comportementsclassiques sont-ils satisfaisants

pour cette classe ? »Oui

Oui

Non

Non




En cas de connexion à une ressource extérieure laréflexion doit porter sur le partage ou la duplication de laressource pour le constructeur/copie et le réaffecteur et surla déconnexion pour le destructeur.

Si ni partage ni duplication ne sont envisageablesle constructeur/copie et le réaffecteur doivent être privésavec un comportement de type déroutement.

inutilisables en dehors de la classeleur utilisation (dans la classe)est une faute qui génère

un déroutement (et un message à l’utilisateur !)


Il faut noter qu’en général, le comportement duréaffecteur correspond « globalement » à détruire puisreconstruire par copie.

La différence sémantique entre réaffectation et construction/copie tient au fait que dans le premier cas l’objet préexiste et qu’il faut gérer l’abandon de son ancien état alors que dans le second l’objet n’est pas encore né.





Exemple classe Ratio :

pas de connexion à des ressources extérieures

copie/réaffectation/destruction champ à champ OK

comportement standard, accès public




Fonctions habituelles


constructeur/défaut : construction sans information

écrire : sortie mode texte dans un flot

saisir : saisie mode texte depuis un flot

Ces fonctions existent pour beaucoup de types T . Il est habituel de se demander si elles peuvent être définies pour la classe en développement et avec quels comportements et accès.




construction / défaut : OK, valeur 0/1, public

écrire : OK, num "/" den, public

saisir : OK, num " " den

ou num "/" den, public




Autres fonctions


Liste des autres fonctions utiles, judicieuses ou tout simplement naturelles pour ce type.

prototype

nom (choix fonction / opérateur)

paramètres, retour, déroutements

sémantique

accès

Penser à d’autres constructeurs et aux fonctions de conversions !




autres constructeurs et convertisseursconstruire (ex Ratio, nouv Z, nouv N) déroutable par DivPar0

conv R (nouv Ratio) nouv R

conv Z (nouv Ratio) nouv Z conv Ratio (nouv Z) nouv Ratio

…

opérations arithmétiquesop + (nouv Ratio, nouv Ratio) nouv Ratio …

comparaisonsop < (nouv Ratio, nouv Ratio) nouv B …

sémantiques claires, accès publics




Rédaction du document de conception détaillée

description algorithmique complète des champs et méthodes prévus dans l’analyse

analyse et conception de toute autre méthode jugée utile en cours de conception


Conception détaillée



Classe toto [ amie de <classes,fonct> ]...

privé...

public...

privé......

Fin de Classe

Bloc Classe contenant une suite de blocs d’accès public ou privé

Syntaxe du document de conception détaillée

Bloc d’accès

Bloc d’accès

Bloc d’accès

Bloc Classe

Nom de la classe




Chargement Allouer N nbclientconstruire (nbclient,0)

Déchargement, Eliminer nbclient

les blocs d’accès public ou privé peuvent contenir

des déclarations de champs

des définitions de méthodes

des blocs de définition de champs statiques

CHC nom N noclient

F ( … ) … Début … Fin[…]





Rappel :

Tout constructeur doit impérativement et dans tous les cas (sauf déroutement interne) construire chacun des champs.

On s’en assurera en adoptant l’habitude de commencer le bloc fonctionnel d’un constructeur par la construction des champs dans l’ordre de leur déclaration.

Tout manquement à cette habitude devra être justifié et témoignera d’un besoin inhabituel. Il faudra par ailleurs contrôler que la propriété désirée est vérifiée.



Spécificités des constructeurs



construire (r ex Ratio, R cons Ratio) Début construire (r.num,R.num) construire (r.den,R.den) Fin, Oublier R, r

construire (r ex Ratio, n nouv Z, d nouv N)Déroutable par DivPar0

Début Si d==0 Alors Dérouter par DivPar0 éphémère() construire (r.num,n) construire (r.den,d) Fin, Eliminer n,d , Oublier r





Rappel :

Tout destructeur doit impérativement et dans tous les cas détruire chacun des champs.

On s’en assurera en terminant le bloc fonctionnel du destructeur par la destruction des champs dans l’ordre inverse de leur déclaration.



Spécificité du destructeur



détruire (r ex Ratio) Début détruire (r.den) détruire (r.num) Fin, Oublier r





Le développement de la structure mémoire (champs) et des fonctions doit se faire conjointement et hors de toute référence aux spécificités d’un programme utilisateur.

réutilisabilitésémantique du type définie intrinsèquement

qualitéoutils adaptés et donc efficaces

efficacité « humaine » : création de l’outil et utilisation(s) dissociées

phases de développement disjointes plus simples « focalisation intellectuelle » facilitée



Il arrive que l’on ait à développer une famille de classes qui correspondent à un même concept appliqué à des types T d’objet différents.

Exemples :pointeurs T est le type de l’objet « pointé »listes, tables T est le type des éléments gérés

On aimerait alors ne réaliser qu’une analyse/conception pour le concept commun à toute la famille.


Patrons de classes



La solution consiste à concevoir un patron ou « moule » de classes, paramètré par le type T. On parle alors de « généricité ».

On obtient alors automatiquement les classes utilisables en « instanciant » le patron avec les types désirés.

Exemples : patron instances, classes obtenues

Adr de T Adr de N, Adr de R,Adr de CHC, …

Liste de T Liste de N, Liste de R,Liste de CHC, …


Définitions algorithmiquesparamètriques / T

Définitions algorithmiquesautomatiques (T => N,R,…)



Le développement d’un patron est similaire à celui d’une classe « normale ».

différences :

nom du type développé <patron> de <T>

T est inconnu (peu de propriétés assurées pour T)

mention de la généricité et du rôle de T dans la FDF

mention des propriétés imposées à T dans la FDF


Cf. cours Structures de Données



Nom :

Adr de T

Rôle : Pointeur de T, objet mémorisant l ’adresse d ’un objet de type T, on dit aussi « pointant sur » un objet de type T.

Interface utilisateur

Propriétés : Aucune propriété particulière imposée au type T

Dépend de : T, type de l ’objet pointé

Variables globales / Champs statiques :

Adr de T Nulle adresse illicite (0)

Fonctions et opérateurs :

construire (ex Adr de T, cons Adr de T) constructeur par copie détruire (ex Adr de T) destructeur op = (ex Adr de T, cons Adr de T) ex Adr de T

réaffecteur

construire (ex Adr de T) constructeur par défautadresse illicite (0)

Adresse (t ex T) nouv Adr de T pointage de t,adresse de t Contenu (a nouv Adr de T) ex T objet “ pointé ” par a,

objet de type T à l‘adresse a


Chapitre II

Héritage

« Héritage ? »

Spécificités de Conception

Héritages complexes


PolymorphismeHéritageClasse« Héritage ? »Spécificités de conceptionHéritages complexes

Définitions

si une classe Y hérite d’une classe X

alors « tout y de type Y est une sorte de X ».

Ainsi y de type Y est alors « poly-typé »

car il est à la fois un Y et un X

y est nativement utilisable en tant que X

toute fonctionnalité de X est disponible pour y



Syntaxes provisoires

Classe Y hérite de X [ amie de … ] Fin de Classe

Y

X

…

Nom : Y Dépend de :

Hérite de : X

Document de conception Fiche de description fonctionnelle

Graphe d’héritage

« Héritage ? »Spécificités de conceptionHéritages complexes



Aspects pratiques

Classe X public N a

f(x nouv X)Fin de Classe

Classe Y hérite de X public N b

g(y nouv Y)Fin de Classe

Classe Z public X x N b

g(y nouv Y)Fin de Classe


X

a

Y hérite de Xcontient un Xnon nommé

(y.X possible)

a

b

Z contient un X x a

b

x



Programme totoDébut Allouer X x Y y Z z

… x.a … y.a … z.x.a f(x) … f(y) … f(z.x) x.b … y.b … z.b g(x) … g(y) … g(z)

… Fin, …


x

a

a

b

a

b

x

y

z

Les champs de X sontdes champs de Y

Les fonctions de paramètres Xsont lançables sur des Y

x n’est qu’un Xz n’est pas un Xlourdeur d’accés


Xn

. . .

. . .N an fn(nouv Xn)

X2 x2

N a2 f2(nouv X2)

Xn xn

xn.a1 f1(xn)

xn. … .x2.x1.a1 f1(xn. … .x2.x1)


Facilité d’accès aux champs et méthodes des classes de base


X1N a1 f1(nouv X1)

X2N a2 f2(nouv X2)

XnN an fn(nouv Xn)

. . . X1 x1N a1 f1(nouv X1)



Développement incrémental


Second niveau de réutilisation de X :

La conception de Y ne consiste qu’au développement des particularités de Y par rapport à X

Gain de temps analyse/conception/codage/test

Compatibilité des diverses versions de X



Factorisation conceptuelle


Pour développer un lot de classes ayant une partie conceptuelle commune il est bon de développer ce tronccommun comme une classe servant de base d ’héritage aux classes désirées

Gain de temps

analyse/conception/codage/test uniques pour le tronc commun

Possibilité de fonctions d’utilisation développées pour la classe de base



Héritage & Encapsulation


encapsulationméthodes héritéesconstruction / destruction

Y hérite de X

accès à champs/méthodes poly-typage

par de X Y/X

méthodes de Y et amies

autres fonctions

?? Toujours

?? ??

Encapsulation dans X

Encapsulation de X dans Y: Encapsulation de l’héritage


Classe

Héritage public

Héritage« Héritage ? »Spécificités de conceptionHéritages complexes

Polymorphisme

Classe Y hérite de X public [ amie de … ] Fin de Classe

Héritage privé

Classe Y hérite de X privé [ amie de … ] Fin de Classe

Syntaxe enrichie

Héritage mentionnédans la FDF

La partie X est en accès public dans Y.


Héritage non mentionné dans FDF

La partie X est en accès privé dans Y.


Héritage« Héritage ? »Spécificités de conceptionHéritages complexes

PolymorphismeClasse

encapsulationconstruction / destruction

Méthodes de Yet amies

Y hérite de X public / privé

Oui / Oui Non / Non

Non / Non

Oui / Oui

Oui / Non

Champs & méthodesde X

public privé Poly-typage

Y/X

Autresfonctions

Oui / Non

Accès à X dans Y Accès à la classe de base




Retour sur méthodes héritées


Y hérite de X

Toute méthode de X est « héritée par Y » (est une méthode de Y) sauf : constructeurs / destructeur / réaffecteur

Les méthodes privées de X sont inaccessibles mêmeaux méthodes de Y.

En héritage privé, les méthodes de X même public sont inaccessibles aux fonctions extérieures à Y.




Constructeurs


Y hérite de X

Tout constructeur de Y doit construire la partie Xpar appel d’une méthode construire appropriée.

On ne reconstruit pas la partie X champs à champsmais globalement !



Classe X public N a,b,somme

construire(x ex X, A nouv N, B nouv N) Début construire(x.a,A) construire(x.b,B) construire(x.somme,a+b) Fin,Eliminer A,B,Oublier x

Fin de Classe

Classe Y hérite de X public N diff

construire(y ex Y, A nouv N, B nouv N) Début construire(y.X,A,B) construire(y.diff,B-A) Fin,Eliminer A,B,Oublier y

Fin de Classe


construire(y.a,A)construire(y.b,B)

...




Destructeur


Y hérite de X

Le destructeur de Y doit détruire la partie X par appelde son destructeur.

On ne détruit pas la partie X champs à champsmais globalement !



Classe X public N a,b,somme

détruire(x ex X) Début détruire(x.a) détruire(x.b) détruire(x.somme) Fin,Oublier x

Fin de Classe

Classe Y hérite de X public N diff

détruire(y ex Y) Début détruire(y.diff) détruire(y.X) Fin,Oublier y

Fin de Classe


détruire(y.a)détruire(y.b)

...




Héritage multiple

On parle d’héritage multiple quandY hérite de plus d’une classe X1 … Xn.

cela revient à dire que « Y est à la fois une sorte de X1, de … et de Xn »

Ainsi y de type Y est alors poly-typé Y , X1, … Xn, ...

Chaque relation Y/Xi est indépendante et équivalente àun héritage simple.

héritage multiplehéritage virtuel


PolymorphismeHéritageClasse« Héritage ? »Spécificités de conceptionHéritages complexes héritage multiple

héritage virtuel

Problèmes spécifiques

Champs de même nom dans Xi et Xj.

Méthodes héritées de Xi et Xj de même prototype aupoly-typage de Y près.

Il faut préciser lequel (laquelle) on utilise !


Classe X1public N a f (nouv X1) ...Fin de Classe

Classe X2public N a f (nouv X2) ...Fin de Classe

Classe Ypublic g(y nouv Y) Début … y.a … y.X2.a … y.X1.a … … f(y)… f(y.X2)… f(y.X1)… Fin … Fin de Classe


héritage virtuel

Accès non ambigus

Syntaxe del’héritage multiple

hérite de X1 public, X2 public



héritage virtuel

Héritage multiple d’une même classe

Un Z contient 2 Xs

Le poly-typage Z/X est ambigu et doît êtreprécisé par un poly-typage non ambigu : z.Y1 ou z.Y2

X

Y1

Z

. . .

Y1

. . .

X

Y2

. . .

X

Y2

Z



héritage virtuel

Héritage virtuel ou partagé

Idée : Y1 et Y2 partagent leur X dans Z

Cet X est hors de Y1 et Y2, mais référencé dans les 2 !

z.Y1.X et z.Y2.X sont associés au même X

X

Y1

Z

. . .

Y1

. . .

X

Y2

Z

Y2

. . .

Flèche brisée :héritage partagé


Document de conception

Graphe Fiche de description fonctionnelled ’héritage


héritage virtuel

Syntaxes

Classe Y hérite de X partagé [ amie de … ] Fin de Classe

Y

X

…

Nom : Y Dépend de :

Hérite de : X partagé

publicprivé



héritage virtuel

Naissance de l’objet partagé

L’objet partagé naît avec l’objet global auquel il appartient

Il est alloué avec cet objet et construit par le constructeurde cet objet.

Tous les objets intermédiaires sont alors informés de sonadresse au moment de leur construction pour le référencer correctement.



héritage virtuel

Chaque type Y héritant d’un ou plusieurs types partageant X partage aussi X.

Chaque constructeur d’un type partageant X doit être à même de construire lui-même cet X ou de récupérer son adresse pour s’y référencer.

construire(y ex Y, … , px nouv Adr de X)Début Si px == NULLE Alors construire(y.X,…) Sinon Associer y.X à Contenu(px) … Fin ... X déjà construit « pointé » par px

Aucun X connu,y est l ’objet global,y.X alloué dans y



héritage virtuel

construire(y ex Y1, …, px nouv Adr de X)Début Si px==NULLE Alors construire(y.X,…) Sinon Associer y.X à Contenu(px)Fin, Eliminer px, Oublier y

// idem pour Y2

construire(z ex Z, …, px nouv Adr de X)Début Si px==NULLE Alors construire(z.X,…) Sinon Associer z.X à Contenu(px) construire (z.Y1, …, Adresse(z.X)) construire (z.Y2, …, Adresse(z.X))Fin, Eliminer px, Oublier z

X

Y1 Y2

Z



héritage virtuel

Allouer Y1 y1 Y2 y2 Z zconstruire(y1,…,NULLE) construire(y2,…,NULLE)construire(z ,…,NULLE)

X

Y1

Z

. . .

Y1

. . .

X

Y2

Z

Y2

. . .

z

Y1

. . .

X

y1

Y2

. . .

X

y2



héritage virtuel

Mort de l’objet partagé

L’objet partagé meurt avec l’objet global auquel il appartient

Il est détruit par le destructeur standard de cet objet etrendu avec cet objet.

Tous les objets intermédiaires sont alors détruits par des destructeurs spéciaux ne s’occupant pas des objets partagés.



héritage virtuel

Chaque type Y partageant au moins un type X doit avoir 2 destructeurs.

détruire_mini(y ex Y) Début // <=> détruire habituel … // sauf destructions des partagés Fin, Oublier y

détruire(y ex Y)Début détruire_mini(y) détruire (y.X)Fin, Oublier y

Lancé par les destructeursdes classes dérivées

Lancé pour détruire lesobjets de type global Y



héritage virtuel

détruire_mini(y ex Y1) Début … Fin, Oublier y

détruire(y ex Y1) Début détruire_mini(y) détruire (y.X) Fin, Oublier y

// idem pour Y2

détruire_mini(z ex Z) Début … détruire_mini(z.Y2) détruire_mini(z.Y1) Fin, Oublier z

détruire(z ex Z) Début détruire_mini(z) détruire (z.X) Fin, Oublier z

X

Y1 Y2

Z


Chapitre III

Polymorphisme

« Polymorphisme ? »

Abstraction

Intérêts


PolymorphismeHéritageClasse« Polymorphisme ? »AbstractionIntérêts

Polymorphisme (fonctionnel)

Faculté d’une méthode d’être remplacée au lancement par une autre selon le type réel de l’un de ses paramètres.

type du paramètre <=> classe de la méthode

méthode remplaçante :

d’une classe dérivée

définie pour le type global (réel) du paramètre

de même prototype (au poly-typage près du paramètre)



Fiche de description fonctionnelle

Syntaxes

<prototype> virtuelle pour <nom d’un paramètre> Début … Fin …

<prototype> virtuelle pour <paramètre>

…

Nom : ?? Dépend de :

Hérite de : ??

« Polymorphisme ? »AbstractionIntérêts

Document de conception


Classe A public … f(a nouv A) virtuelle pour a Début écrire("f de A", OUT) Fin,Eliminer a g(a nouv A) Début écrire("g de A", OUT) Fin,Eliminer aFin de Classe

Classe B hérite de A public public … f(b nouv B) Début écrire("f de B", OUT) Fin,Eliminer b g(b nouv B) Début écrire("g de B", OUT) Fin,Eliminer bFin de Classe


Redéfinitionde la fonction f de A



Programme PolymDébut

Allouer Adr de A pA Cr c

écrire ("A ou B ? ",OUT) saisir (c,IN) construire(pA, selon c=='A' éval A durable() ou B durable() ) f(Contenu(pA)) g(Contenu(pA))Fin, Eliminer Contenu(pA),pA,c


$ PolymA ou B ? Af de Ag de A$

$ PolymA ou B ? Bf de Bg de A$

C’est toujours un A

C ’est un Adans un B !



PolymorphismeHéritageClasse« Polymorphisme ? »AbstractionIntérêts

Méthodes abstraites

Une méthode virtuelle peut même ne pas être définie algorithmiquement pour sa classe de base A.

Elle est alors déclarée abstraite.

<prototype> abstraite pour <nom d’un paramètre>…

<prototype> abstraite pour <paramètre>

…

Nom : ?? Dépend de :

Hérite de : ??

Pas de corps fonctionnel



Classes abstraites

Une méthode abstraite n’existant pas pour sa classe A, elle ne peut être lancée sur des objets dont le type global est Aou un type dérivé de A n’ayant pas défini cette méthode.

Ces classes, incomplètes, sont dites abstraites.

Elles ne peuvent être directement instanciées ; tout objetd’un de ces types doit être objet hérité par un autre pour lequel la méthode est définie.




Les classes abstraites ne peuvent donc servir que commebases d’héritage.

Elles permettent de formaliser l’existence de fonctionscommunes à leurs classes dérivées même si ces fonctionsne peuvent être définies à leur niveau.




Définition d’un interface fonctionnel commun aux classesdérivées conservant la spécificité de comportement de ces fonctions pour chaque type.

Développement unique pour la classe de base de fonctions qui utilisent ces fonctions virtuelles ou abstraites.


Intérêts du polymorphisme

Factorisation sémantique conservant les spécificités algorithmiques internes.



Gestion efficace et utile de collections d’objets hétérogènes de même nature sémantique.

Ex : liste de Dessins (Cercles, Carrés, …)

Modularité améliorée :

pas de spécificités à gérer dans le code utilisateur

Ex : pour chaque Dessin D de la liste Dessiner (D,écran)

l’ajout d’une nouvelle classe dérivée ne nécessite pas de modification des fonctions utilisatrices

gains : simplicité du code / évolution modulaire temps / sécurité



Documents

Conception Orientée Objet