Juillet 
2014 
h"p://www.isima.fr/~loic
2 
Plan 
1. Génie 
logiciel 
et 
historique 
2. Concepts 
objets 
Ces 
transparents 
ont 
été 
conçus 
originellement 
par...
1. 
Génie 
Logiciel
4 
Plan 
• Pourquoi 
avons-­‐nous 
besoin 
du 
génie 
logiciel 
? 
• Les 
problèmes 
liés 
à 
la 
concepNon 
de 
logiciels...
5 
But 
: 
améliorer 
la 
qualité 
des 
logiciels 
• UNlisateurs 
§ Logiciel 
répondant 
bien 
aux 
besoins 
§ Fiable 
e...
6 
Génie 
logiciel 
• Résoudre 
les 
problèmes 
liés 
à 
la 
complexité 
§ ê 
Coûts 
de 
développement 
et 
de 
maintena...
7 
Facteurs 
de 
qualité 
• Fiable 
§ dès 
la 
concepNon 
! 
• Efficace 
• Modifiable 
• Intelligible 
• Interopérable
8 
#include <stdio.h> 
#include <math.h> 
#include <unistd.h> 
#include <sys/ioctl.h> 
main() { 
short a[4];ioctl 
(0,TIOC...
9 
RéuNlisabilité 
(1) 
• Temps 
de 
développement 
§ Ne 
pas 
réinventer 
la 
roue 
à 
chaque 
étape 
§ Même 
algorithm...
10 
RéuNlisabilité 
(2) 
• Avantages 
§ Plus 
un 
code 
est 
uNlisé, 
plus 
il 
devient 
fiable 
§ DétecNon 
précoce 
de...
11 
EvoluNon 
du 
logiciel 
• L’époque 
héroïque 
• Les 
premiers 
langages 
évolués 
• La 
noNon 
de 
sous-­‐programme 
•...
12 
L’époque 
héroïque 
• Ordinateurs 
peu 
nombreux 
et 
réservés 
aux 
insNtuNons 
gouvernementales 
§ Peu 
de 
choses ...
IBM 
Mark 
I 
13 
mov ah, 00h 
mov al, 13h 
int 10h 
mov ax,0a000h 
mov es,ax 
mov ax,320 
mul 100 
add ax,160 
mov di,ax ...
Les 
ordinateurs 
se 
démocraNsent 
• Formalismes 
plus 
simples 
§ Premiers 
langages 
structurés 
(FORTRAN) 
§ Règne 
...
15 
PL(I,J)=(2*I-1)*4*PL(I-1,J)/I-(I-1)*PL(I-2,J)/I 
http://pagesperso.lina.univ-nantes.fr/info/perso/permanents/vailly/En...
16 
Sous-­‐programme 
(1) 
• MoNvaNon 
: 
§ traitement 
des 
tâches 
apparaissant 
de 
manière 
répéNNve 
dans 
les 
prog...
17 
Sous-­‐programme 
(2) 
• Abstrac(on 
procédurale 
§ Tout 
appel 
de 
sous 
programme 
apparaît 
atomique 
• Problèmes...
18 
Module 
(1) 
• AppariNon 
de 
"gros" 
logiciels 
de 
gesNon 
• Chaque 
module 
lié 
à 
une 
foncNonnalité 
§ gesNon 
...
19 
Module 
(2) 
• EnNté 
indépendante 
regroupant 
les 
sous-­‐programmes 
et 
les 
données 
sur 
lesquelles 
ils 
travai...
20 
Type 
abstrait 
de 
données 
(1) 
• Structure 
de 
données 
avec 
traitements 
associés 
• AppariNon 
du 
schéma 
modè...
Type 
abstrait 
de 
données 
(2) 
La 
pile 
21 
Sommet 
? 
créer() 
empiler() 
dépiler() 
estVide() 
Autres 
exemple 
: 
u...
2. 
Concepts 
objets
23 
Plan 
• DéfiniNons 
§ Objet 
§ Classe 
• NotaNon 
(UML) 
• RelaNons 
§ Héritage 
§ AgrégaNon 
§ AssociaNon
RéificaNon 
? 
24
DéfiniNon 
Un 
objet 
est 
une 
capsule 
logicielle 
oblaNve 
avec 
un 
tropisme 
conaNf 
dont 
l’hétéronomie 
est 
la 
ma...
26 
Objet 
• EnNté 
cohérente 
rassemblant 
des 
données 
et 
le 
code 
travaillant 
sur 
ces 
données 
• Données 
: 
§ A...
27 
Classe 
• Moule 
/ 
Modèle 
/ 
Fabrique 
à 
objets 
: 
§ donnée 
qui 
décrit 
des 
objets 
• Expression 
de 
la 
noNo...
ReprésentaNon 
UML 
28 
Voiture 
# 
NombreDeVoitures 
: 
enNer 
# 
Marque 
: 
chaine 
# 
ImmatriculaNon 
: 
chaîne 
# 
Vit...
29 
RelaNon 
d’instanciaNon 
• Permet 
d’obtenir 
un 
objet 
à 
parNr 
de 
la 
classe 
§ La 
classe 
décrit 
un 
objet 
•...
30 
Exemples 
d’instanciaNon 
Classe 
Voiture 
# 
NombreDeVoitures 
: 
enNer 
# 
Marque 
: 
chaine 
# 
ImmatriculaNon 
: 
...
31 
Membres 
de 
classe/instance 
(1) 
• A"ributs 
d’instance 
= 
une 
valeur 
par 
objet 
§ vitesse 
d’un 
véhicule 
§ ...
32 
Membres 
de 
classe/instance 
(2) 
• Méthode 
d’instance 
= 
agit 
sur 
un 
objet 
parNculier 
§ Accélérer, 
freiner ...
33 
Principe 
d’encapsulaNon 
(1) 
• SéparaNon 
forte 
Interface/ImplémentaNon 
• Interface 
= 
parNe 
visible 
d 
’un 
ob...
34 
Principe 
d’encapsulaNon 
(2) 
• AbstracNon 
procédurale 
Un 
appel 
de 
message 
est 
atomique 
§ Les 
objets 
agiss...
Principe 
d'encapsulaNon 
(3) 
35 
a"ributs 
méthodes 
privées 
méthodes 
publiques 
interface 
messages 
Implémentation 
...
36 
Principe 
de 
Demeter 
• On 
ne 
parle 
qu'à 
ses 
amis 
! 
• Une 
méthode 
accède 
exclusivement 
aux 
éléments 
suiv...
37 
Des 
interfaces 
mulNples 
? 
• Certains 
langages 
perme"ent 
à 
un 
objet 
de 
disposer 
de 
plusieurs 
interfaces 
...
38 
NoNon 
de 
logiciel 
orienté 
objet 
• CollecNon 
d’objets 
en 
interacNon 
! 
Une 
nouvelle 
abstracNon 
: 
l’exécuNo...
39 
Créer 
un 
logiciel 
orienté 
objet 
(1) 
• 5 
grands 
principes 
de 
BOOCH 
1. Décomposable 
§ ParNNonner 
le 
logic...
40 
Créer 
un 
logiciel 
orienté 
objet 
(2) 
3. Compréhensible 
§ Fondé 
sur 
la 
qualité 
de 
la 
documentaNon 
§ Chaq...
41 
Créer 
un 
logiciel 
orienté 
objet 
(3) 
4. ConNnu 
§ Un 
changement 
faible 
de 
spécificaNon 
doit 
entraîner 
le ...
42 
Typage 
des 
objets 
• une 
classe 
= 
un 
type 
• Deux 
catégories 
de 
langages 
à 
objets 
§ Typage 
fort 
(et 
st...
43 
Typage 
fort 
(et 
staNque) 
• Un 
objet 
est 
affecté 
à 
une 
classe 
à 
la 
compilaNon 
• VérificaNon 
de 
l’adéqua...
44 
Typage 
faible 
(et 
dynamique) 
• L’informaNon 
est 
liée 
non 
à 
l’adresse 
mais 
au 
contenu 
de 
l’objet 
• Possi...
45 
Les 
relaNons 
fondamentales 
• Héritage 
Concept 
de 
GénéralisaNon/spécialisaNon 
RelaNon 
: 
Est 
une 
version 
spé...
46 
Héritage 
• Concept 
naturel 
de 
GénéralisaNon 
/ 
SpécialisaNon 
§ classes 
représentées 
sous 
forme 
d’arbres 
gé...
47 
Forme 
# 
NombreDeFormes 
: 
enNer 
# 
couleur 
: 
Couleur 
# 
x 
: 
enNer 
# 
y 
: 
enNer 
+ 
afficher() 
+ 
getX() 
...
48 
Propriétés 
de 
la 
classe 
fille 
• Reprend 
les 
caractérisNques 
de 
la 
super 
classe 
§ A"ributs 
§ Méthodes 
•...
49 
Comment 
travailler 
avec 
l’héritage 
? 
• Construire 
un 
système 
ex 
nihilo 
§ IdenNfier 
tous 
les 
composants 
...
50 
Un 
parc 
de 
véhicules 
• On 
souhaite 
fournir 
un 
modèle 
de 
parc 
de 
véhicules 
pouvant 
fournir 
: 
§ des 
vo...
51 
VéhiculeRoulant 
Véhicule 
ModélisaNon 
possible 
d'un 
parc 
hétérogène 
de 
véhicules 
Ajouter 
un 
avion 
???
52 
VéhiculeRoulant 
Véhicule 
Première 
approche
53 
VéhiculeRoulant 
Véhicule 
Deuxième 
approche 
VéhiculeVolant
54 
Classe 
abstraite 
• ModélisaNon 
d’un 
concept 
plutôt 
que 
d’objets 
réels 
§ Pas 
d’instance 
§ Définit 
des 
mé...
55 
Polymorphisme 
• Une 
même 
méthode 
prend 
plusieurs 
formes 
• Forme 
faible 
§ Surcharge 
de 
méthode 
– 
overload...
56 
Exemple 
(1) 
• Méthode 
à 
différencier 
selon 
les 
objets 
graphiques 
[ 
Forme 
] 
: 
l’affichage 
• Code 
sans 
l...
57 
Exemple 
(2) 
• Des 
méthodes 
spécifiques 
• Chaque 
classe 
définit 
le 
comportement 
qui 
lui 
est 
propre 
• Elle...
Mise 
en 
oeuvre 
58 
objets 
objets 
de 
classe 
code 
Cercle 
méthode 
1 
méthode 
2 
… 
Afficher 
… 
méthode 
n 
Ligne ...
59 
Avantages 
de 
l’héritage 
(1) 
• Partage 
de 
code 
§ RéuNlisabilité 
§ Fiabilité 
§ Le 
code 
des 
classes 
les 
...
60 
Avantages 
de 
l’héritage 
(2) 
• Taille 
de 
code 
source 
plus 
faible 
(factorisaNon) 
• Maintenance 
facilitée 
§...
61 
Dangers 
de 
l’héritage 
(1) 
Base 
Intermédiaire 1 
Intermédiaire 2 
Feuille 2 Feuille 3 
Exemple d'une classe 
inter...
Dangers 
de 
l’héritage 
(2) 
62 
• ViolaNon 
du 
principe 
d’encapsulaNon 
§ Règle 
: 
transmission 
intégrale 
de 
la 
...
63 
Dangers 
de 
l’héritage 
(3) 
• Héritage 
de 
construcNon 
§ Rajouter 
des 
méthodes 
sans 
conserver 
la 
noNon 
de ...
Héritage 
mulNple 
• ModélisaNon 
de 
principes 
naturels 
• Risques 
de 
collision 
de 
noms 
sur 
les 
classes 
parent 
...
65 
Héritage 
à 
répéNNon 
• DuplicaNon 
de 
V 
dans 
H 
§ (une 
fois 
via 
B 
et 
une 
fois 
via 
A) 
§ avancer() 
? 
§...
Interface 
• FormalisaNon 
de 
la 
noNon 
d'interface 
§ Ensemble 
de 
méthodes 
virtuelles 
§ Similaire 
à 
une 
classe...
67 
<<interface>> 
FloDant 
+ 
floDer() 
+ 
avancer() 
Véhicule 
+ 
avancer() 
étend 
étend 
implémente 
pas 
de 
conflit ...
68 
Radar 
Avion 
Interface 
Détecteur 
Interface 
MachineVolante 
• SoluNon 
? 
§ Besoins 
du 
logiciel 
§ Culture 
du ...
ComposiNon 
/ 
AgrégaNon 
• ModélisaNon 
de 
la 
relaNon 
« 
est 
composé 
de 
» 
§ ComposiNon, 
appartenance, 
groupage,...
70 
Objet 
agrégé 
Moteur 
Chassis 
Roue 
Voiture 
4 
1 
1 
1 
1 
1 
Cardinalités 
: 
Une 
voiture 
agrège 
quatre 
roues ...
71 
AlternaNve 
à 
l’héritage 
mulNple 
? 
1 
1 
1 
1 
1 
1 
1 
1
72 
AssociaNon 
• Modélise 
des 
concepts 
assez 
flous 
§ Uses 
A 
§ Est 
en 
associaNon 
avec 
§ Communique 
avec 
• ...
73 
ZOO 
– 
V1 
Zoo 
Cage 
Gardien 
Animal 
1 
* 
1 
* 
1 
* 
* 
* 
nourrit 
1 
* 
habite 
* 
ne"oie 
*
74 
ZOO 
– 
V2 
Zoo 
Cage 
Gardien 
Animal 
1 
* 
1 
* 
* 
* 
nourrit 
1 
* 
* 
ne"oie 
*
90 
80 
70 
60 
généricité, 
excepNons 
opérateurs 
classes 
base 
Simula 
Pascal 
Algol 
C 
Objec(ve 
C 
Smalltalk 
Eiffe...
Visibilité 
des 
a"ributs 
et 
des 
méthodes 
en 
UML 
? 
+ public 
: 
tout 
le 
monde 
§ Méthodes 
de 
l'interface 
publ...
Fourmi 
ZZ 
? 
77 
Fourmiliere 
Fourmi 
-­‐energie 
: 
unsigned 
int 
-­‐id 
: 
unsigned 
int 
-­‐energieMax 
: 
unsigned ...
Prochain SlideShare
Chargement dans…5
×

Introduction à l'objet - Deuxième année ISIMA

919 vues

Publié le

Cours d'introduction à l'objet. Préalable du cours C++ et Java

Publié dans : Formation
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
919
Sur SlideShare
0
Issues des intégrations
0
Intégrations
292
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Introduction à l'objet - Deuxième année ISIMA

  1. 1. Juillet 2014 h"p://www.isima.fr/~loic
  2. 2. 2 Plan 1. Génie logiciel et historique 2. Concepts objets Ces transparents ont été conçus originellement par Bruno-­‐Laurent GARCIA, ISIMA AmélioraNons successives de David HILL et Christophe DUHAMEL, ISIMA
  3. 3. 1. Génie Logiciel
  4. 4. 4 Plan • Pourquoi avons-­‐nous besoin du génie logiciel ? • Les problèmes liés à la concepNon de logiciels • Les qualités d’un bon logiciel • L’évoluNon de la programmaNon au cours des âges
  5. 5. 5 But : améliorer la qualité des logiciels • UNlisateurs § Logiciel répondant bien aux besoins § Fiable et sûr § Bonne documentaNon • Développeurs § Logiciel facile à faire évoluer et à maintenir § Bonne documentaNon
  6. 6. 6 Génie logiciel • Résoudre les problèmes liés à la complexité § ê Coûts de développement et de maintenance § Obtenir des logiciels saNsfaisants pour tous • Comment ? § Maîtriser la concepNon d’un logiciel § Prévoir son évoluNon • OuNl fondamental : l'abstracNon • Problème : subjecNvité de l’abstracNon
  7. 7. 7 Facteurs de qualité • Fiable § dès la concepNon ! • Efficace • Modifiable • Intelligible • Interopérable
  8. 8. 8 #include <stdio.h> #include <math.h> #include <unistd.h> #include <sys/ioctl.h> main() { short a[4];ioctl (0,TIOCGWINSZ,&a);int b,c,d=*a,e=a[1];float f,g, h,i=d/2+d%2+1,j=d/5-1,k=0,l=e/ 2,m=d/4,n=.01*e,o=0,p=.1;while ( printf("x1b[Hx1B[?25l"),!usleep( 79383)){for (b=c=0;h=2*(m-c)/i,f=- .3*(g=(l-b)/i)+.954*h,c<d;c+=(b=++ b%e)==0)printf("x1B[%dm ",g*g>1-h *h?c>d-j?b<d-c||d-c>e-b?40:100:b<j ||b>e-j?40:g*(g+.6)+.09+h*h<1?100: 47:((int)(9-k+(.954*g+.3*h)/sqrt (1-f*f))+(int)(2+f*2))%2==0?107 :101);k+=p,m+=o,o=m>d-2*j? -.04*d:o+.002*d;n=(l+= n)<i||l>e-i?p=-p ,-n:n;}} Ce qu’il ne faut pas faire …. Peter Eastman IOCCC 2011
  9. 9. 9 RéuNlisabilité (1) • Temps de développement § Ne pas réinventer la roue à chaque étape § Même algorithme sous diverses formes • Différents langages de programmaNon • Différentes structures de données • Différents environnements • Obstacles § DocumentaNon inadéquate § Problèmes de diffusion § Interfaçage avec le code local
  10. 10. 10 RéuNlisabilité (2) • Avantages § Plus un code est uNlisé, plus il devient fiable § DétecNon précoce des bogues et manquements • Coûts de maintenance inférieurs • Un module validé n’a plus à être vérifié ! • RéuNliser le code c’est bien ... • RéuNliser la concepNon c’est mieux ! § Éliminer certaines étapes de concepNon sur des problèmes semblables § Englober en une unité foncNonnelle unique les travaux de concepNon et d’implémentaNon
  11. 11. 11 EvoluNon du logiciel • L’époque héroïque • Les premiers langages évolués • La noNon de sous-­‐programme • La programmaNon modulaire • Les types abstraits de données • Les objets
  12. 12. 12 L’époque héroïque • Ordinateurs peu nombreux et réservés aux insNtuNons gouvernementales § Peu de choses demandées aux ordinateurs § Interface sommaire voire inexistante § PeNts programmes en langage machine puis en assembleur § Un seul concepteur ou une très peNte équipe
  13. 13. IBM Mark I 13 mov ah, 00h mov al, 13h int 10h mov ax,0a000h mov es,ax mov ax,320 mul 100 add ax,160 mov di,ax mov al, 255 mov es:[di],al 0100010001010010 0001000111001110 1111010001010100 0101010010000101 1111000010101001 1010100101011010 1011101011111000 0101010101010101 1011011111110100 1010101010101010 0101010101111101 1001010101010101
  14. 14. Les ordinateurs se démocraNsent • Formalismes plus simples § Premiers langages structurés (FORTRAN) § Règne du « spaghep » • Programmes plus ambiNeux § Premières équipes de travail § Découpage en plusieurs programmes reliés § Premiers problèmes liés à la communicaNon • Découpage / Interfaçage • Première idée : abstracNon de l’implémentaNon = descripNon des interfaces 14
  15. 15. 15 PL(I,J)=(2*I-1)*4*PL(I-1,J)/I-(I-1)*PL(I-2,J)/I http://pagesperso.lina.univ-nantes.fr/info/perso/permanents/vailly/Enseignement/EMIAGE/EnDev/ModuleA206EMiageV2.4/c2/A206_2.html
  16. 16. 16 Sous-­‐programme (1) • MoNvaNon : § traitement des tâches apparaissant de manière répéNNve dans les programmes • Boîte noire § L’uNlisateur ne connaît que le prototype : • Paramètres • FoncNonnalités
  17. 17. 17 Sous-­‐programme (2) • Abstrac(on procédurale § Tout appel de sous programme apparaît atomique • Problèmes : § Nommage des idenNficateurs § Collisions possibles entre les idenNficateurs de l’uNlisateur et ceux des sous-­‐programmes.
  18. 18. 18 Module (1) • AppariNon de "gros" logiciels de gesNon • Chaque module lié à une foncNonnalité § gesNon client, gesNon compte, … • CommunicaNon par messages • Extension naturelle des sous-­‐programmes
  19. 19. 19 Module (2) • EnNté indépendante regroupant les sous-­‐programmes et les données sur lesquelles ils travaillent § SéparaNon entre parNe publique et parNe privée § La parNe publique définit l’interface ou contrat d’uNlisaNon • Problèmes majeurs § Impossible de dupliquer un module § Une seule copie des données sur lesquelles un module est capable de travailler § A"enNon au découpage ! il est tentant de vouloir faire des modules trop peNts et de perdre ainsi en efficacité
  20. 20. 20 Type abstrait de données (1) • Structure de données avec traitements associés • AppariNon du schéma modèle/instance § Autant d’instances que nécessaire : § Les données sont dupliquées • NoNon d’interface § Liste des opéraNons disponibles § ImplémentaNon cachée des données • AbstracNon des données "On connaît une donnée au travers des opéra2ons disponibles dessus"
  21. 21. Type abstrait de données (2) La pile 21 Sommet ? créer() empiler() dépiler() estVide() Autres exemple : une file, une liste chaînée …
  22. 22. 2. Concepts objets
  23. 23. 23 Plan • DéfiniNons § Objet § Classe • NotaNon (UML) • RelaNons § Héritage § AgrégaNon § AssociaNon
  24. 24. RéificaNon ? 24
  25. 25. DéfiniNon Un objet est une capsule logicielle oblaNve avec un tropisme conaNf dont l’hétéronomie est la marque de la durée de l’éphémère et de la hoirie ! 25 -­‐-­‐ Serge Miranda, Université de Nice
  26. 26. 26 Objet • EnNté cohérente rassemblant des données et le code travaillant sur ces données • Données : § A"ributs § Données membres • Code : § Méthodes
  27. 27. 27 Classe • Moule / Modèle / Fabrique à objets : § donnée qui décrit des objets • Expression de la noNon de classe d’équivalence • Comment représenter ? § Unified Modeling Language
  28. 28. ReprésentaNon UML 28 Voiture # NombreDeVoitures : enNer # Marque : chaine # ImmatriculaNon : chaîne # VitesseCourante : réel # VitesseMaximale : réel + démarrer() + accélérer(pourcentage : réel) + arrêter() + reculer() + Créer une voiture() + Détruire une voiture() Nom de la classe DescripNon des a"ributs ou données membres DescripNon des méthodes = code associé aux données
  29. 29. 29 RelaNon d’instanciaNon • Permet d’obtenir un objet à parNr de la classe § La classe décrit un objet • Données membres • Méthodes § L’objet est un état de la classe • Tous les objets d ’une même classe ont la même structure • Les données prennent des valeurs significaNves pour un objet parNculier • C’est une instance de la classe
  30. 30. 30 Exemples d’instanciaNon Classe Voiture # NombreDeVoitures : enNer # Marque : chaine # ImmatriculaNon : chaîne # VitesseCourante : réel # VitesseMaximale : réel # Couleur : Gamme + démarrer() + accélérer(pourcentage : réel) + arrêter() + reculer() + Créer une voiture() + Détruire une voiture() Instances InstanciaNon "Porsche" "ISI 063 FAST" 180.1 270.0 "Renault" "ISI 063 NORM" 50.0 160.0
  31. 31. 31 Membres de classe/instance (1) • A"ributs d’instance = une valeur par objet § vitesse d’un véhicule § couleur d’un véhicule • A"ributs de classe = partagés par tous les objets d’une même classe § nombre de véhicules présents à un instant donné § gamme de couleurs disponibles
  32. 32. 32 Membres de classe/instance (2) • Méthode d’instance = agit sur un objet parNculier § Accélérer, freiner § Donner la vitesse courante § Donner la couleur • Méthode de classe = agit sur toute la classe § Créer ou détruire une voiture § Donner la gamme de couleurs disponibles § Donner le nombre de voitures créées
  33. 33. 33 Principe d’encapsulaNon (1) • SéparaNon forte Interface/ImplémentaNon • Interface = parNe visible d ’un objet § Ensemble de messages paramétrés § Communiquer avec un objet = envoi de messages = appel direct de méthode (en praNque) • ImplémentaNon cachée § A"ributs / Méthodes § ImplémentaNon d’un objet modifiable sans que l’uNlisateur ne s’en aperçoive : il suffit de ne pas modifier l’interface
  34. 34. 34 Principe d’encapsulaNon (2) • AbstracNon procédurale Un appel de message est atomique § Les objets agissent comme des boîtes noires § L’uNlisateur n’a aucun contrôle sur les traitements associés à son message • AbstracNon de données Un objet n’est accessible que via ses messages § L’uNlisateur n’a aucun renseignement sur la structure interne d’un objet
  35. 35. Principe d'encapsulaNon (3) 35 a"ributs méthodes privées méthodes publiques interface messages Implémentation Privée Interface Publique
  36. 36. 36 Principe de Demeter • On ne parle qu'à ses amis ! • Une méthode accède exclusivement aux éléments suivants : § Ses arguments et les variables temporaires créés qu'elle crée § Les a"ributs de l’objet courant § Les a"ributs de la classe de l’objet courant § Les variables globales
  37. 37. 37 Des interfaces mulNples ? • Certains langages perme"ent à un objet de disposer de plusieurs interfaces Choix d’interface avant d’accéder aux messages Développeurs Chef de projet Big boss
  38. 38. 38 NoNon de logiciel orienté objet • CollecNon d’objets en interacNon ! Une nouvelle abstracNon : l’exécuNon Un système d’objets doit toujours donner l’impression d’être monolithique • Un objet cible peut être : § Situé sur la machine courante ou distante § AcNf / en sauvegarde (persistance) / pas encore créé
  39. 39. 39 Créer un logiciel orienté objet (1) • 5 grands principes de BOOCH 1. Décomposable § ParNNonner le logiciel en modules d’objets indépendants ne nécessitant que de connaître les interfaces 2. (Re)Composable § Les différents modules doivent pouvoir s’assembler pour former de nouveaux modules
  40. 40. 40 Créer un logiciel orienté objet (2) 3. Compréhensible § Fondé sur la qualité de la documentaNon § Chaque module doit pouvoir être compris par une personne n’appartenant pas à son équipe de développement. § Les dépendances entre modules doivent être claires
  41. 41. 41 Créer un logiciel orienté objet (3) 4. ConNnu § Un changement faible de spécificaNon doit entraîner le minimum de modificaNons dans les modules 5. Protégé § Lorsqu’une erreur apparaît dans un module, celui-­‐ci doit s’en rendre compte et averNr les autres
  42. 42. 42 Typage des objets • une classe = un type • Deux catégories de langages à objets § Typage fort (et staNque) [C++ , JAVA] § Typage faible (et dynamique) [ObjecNve C, Javascript, PHP]
  43. 43. 43 Typage fort (et staNque) • Un objet est affecté à une classe à la compilaNon • VérificaNon de l’adéquaNon objet/message à la compilaNon • Impossible d’envoyer un message non traitable • Facile à déboguer et à me"re au point • L’informaNon de type est liée au nom (idenNficateur) de l’objet et donc à son adresse mémoire
  44. 44. 44 Typage faible (et dynamique) • L’informaNon est liée non à l’adresse mais au contenu de l’objet • Possible de modifier le typage de l’objet au cours du temps • Grande souplesse notamment lors du prototypage d’une applicaNon • VérificaNon de l’adéquaNon objet/message à l ’exécuNon § Erreur § Transmission ou délégaNon vers un autre objet
  45. 45. 45 Les relaNons fondamentales • Héritage Concept de GénéralisaNon/spécialisaNon RelaNon : Est une version spécialisée de (Is A) • ComposiNon / agrégaNon Concept de composiNon RelaNon : ConNent, regroupe, possède (Has A) • AssociaNon Concept d’objets communiquants RelaNon : communique avec (Uses A)
  46. 46. 46 Héritage • Concept naturel de GénéralisaNon / SpécialisaNon § classes représentées sous forme d’arbres généalogiques • Vocabulaire : § Classe spécialisée : sous classe, classe fille, classe dérivée § Classe générale : super classe, classe mère § La classe spécialisée dérive de sa classe mère • Idée fondamentale : M F § La sous classe hérite de toutes les méthodes et tous les a"ributs de sa classe mère auxquels elle rajoute les siens
  47. 47. 47 Forme # NombreDeFormes : enNer # couleur : Couleur # x : enNer # y : enNer + afficher() + getX() : enNer + setX( valeur : enNer) + Créer une forme() + Détruire une forme() Rectangle # largeur : enNer # hauteur : enNer + afficher() + Créer un rectangle() + Détruire un rectangle() Concept de base Cercle # rayon : enNer + afficher() + Créer un cercle() + Détruire un cercle() Concepts spécialisés Omission des geDers/seDers Une classe Point ?
  48. 48. 48 Propriétés de la classe fille • Reprend les caractérisNques de la super classe § A"ributs § Méthodes • Ajoute les siennes § A"ributs (instance ou classe) § Méthode (instance ou classe) • Possibilité de répondre à de nouveaux messages • Possibilité de répondre de manière différente aux messages de la super classe
  49. 49. 49 Comment travailler avec l’héritage ? • Construire un système ex nihilo § IdenNfier tous les composants § Procéder par généralisaNon en factorisant les caractérisNques communes • Etendre un système § Ajouter les nouvelles classes dans le graphe d’héritage en idenNfiant les différences avec les classes existantes § « programmaNon différenNelle »
  50. 50. 50 Un parc de véhicules • On souhaite fournir un modèle de parc de véhicules pouvant fournir : § des voitures § des camions § des bateaux § des hélicoptères • Tous sont des véhicules § FactorisaNon au plus haut par une classe Véhicule § Les voitures et les camions sont des véhicules terrestres pouvant découler d’une même classe
  51. 51. 51 VéhiculeRoulant Véhicule ModélisaNon possible d'un parc hétérogène de véhicules Ajouter un avion ???
  52. 52. 52 VéhiculeRoulant Véhicule Première approche
  53. 53. 53 VéhiculeRoulant Véhicule Deuxième approche VéhiculeVolant
  54. 54. 54 Classe abstraite • ModélisaNon d’un concept plutôt que d’objets réels § Pas d’instance § Définit des méthodes abstraites • Pas d’implémentaNon : uniquement une spécificaNon § Peut définir des a"ributs • UNlisée comme super classe d’une hiérarchie § Exemples : Véhicule, Forme § Aucun intérêt d’avoir des instances ð classes dérivées • Définit un cadre de travail pour le polymorphisme F Une même méthode prend plusieurs formes !
  55. 55. 55 Polymorphisme • Une même méthode prend plusieurs formes • Forme faible § Surcharge de méthode – overloading § Méthodes de signatures différentes Voiture + avancer(temps : enNer) + avancer(distance : réel) Voiture + afficher(); Véhicule + afficher(); • Forme forte § RedéfiniNon – overriding § AcNons différentes pour des classes d'une même hiérarchie
  56. 56. 56 Exemple (1) • Méthode à différencier selon les objets graphiques [ Forme ] : l’affichage • Code sans la noNon d’objet : Pour chaque forme : Selon (TypeObjet) cas CERCLE AffichageCercle(Objet) cas RECTANGLE AffichageRectangle(Objet) Fin Selon Fin Pour
  57. 57. 57 Exemple (2) • Des méthodes spécifiques • Chaque classe définit le comportement qui lui est propre • Elle peut hériter du code de la classe mère si bon lui semble • Code très simplifié : Pour chaque forme : [ objet Afficher] Fin Pour
  58. 58. Mise en oeuvre 58 objets objets de classe code Cercle méthode 1 méthode 2 … Afficher … méthode n Ligne méthode 1 méthode 2 … Afficher … méthode n Carré méthode 1 méthode 2 … Afficher … méthode n pour chaque objet de la collection [objet Afficher] fin Pour [cercle Afficher] [ligne Afficher] [carré Afficher] cercle ligne carré
  59. 59. 59 Avantages de l’héritage (1) • Partage de code § RéuNlisabilité § Fiabilité § Le code des classes les plus hautes dans la hiérarchie est uNlisé le plus souvent : il gagne vite en fiabilité • ModélisaNon d’un concept très naturel
  60. 60. 60 Avantages de l’héritage (2) • Taille de code source plus faible (factorisaNon) • Maintenance facilitée § Modifier l’interface d’une classe dérivée n’impose pas de recompiler toutes celles qui sont au dessus § Modifier l’implémentaNon d’une classe n’impose pas de recompiler la hiérarchie
  61. 61. 61 Dangers de l’héritage (1) Base Intermédiaire 1 Intermédiaire 2 Feuille 2 Feuille 3 Exemple d'une classe intermédiaire superfétatoire (Intermédiaire 1) Feuille 1 • A"enNon à la hiérarchie ! • Trop lourde, elle nuit à l’efficacité du code !
  62. 62. Dangers de l’héritage (2) 62 • ViolaNon du principe d’encapsulaNon § Règle : transmission intégrale de la mère à la fille § Erreurs sémanNques ( Manchot / penguin ) • Héritage sélec(f avec certains langages ! voler() Choisir les méthodes ou les a"ributs à faire hériter
  63. 63. 63 Dangers de l’héritage (3) • Héritage de construcNon § Rajouter des méthodes sans conserver la noNon de généralisaNon/spécialisaNon • Dériver rectangle de ligne en rajoutant une largeur § Dériver là où une différence d’a"ribut suffirait • Dériver des animaux en foncNon de la couleur du pelage ð manque de discriminaNon foncNonnelle
  64. 64. Héritage mulNple • ModélisaNon de principes naturels • Risques de collision de noms sur les classes parent § Certains langages perme"ent de préfixer les noms des membres • Se transforme très rapidement en héritage à répéNNon ! 64 • Plusieurs super classes pour une même sous classe !
  65. 65. 65 Héritage à répéNNon • DuplicaNon de V dans H § (une fois via B et une fois via A) § avancer() ? § ImmatriculaNon ? • Très fréquent avec les bibliothèques • Mécanismes spécifiques (C++) Véhicule + avancer() avancer() ? -­‐ immatriculaNon ISI -­‐ 63 -­‐ FR V B A H ISI -­‐ 63 -­‐ FR
  66. 66. Interface • FormalisaNon de la noNon d'interface § Ensemble de méthodes virtuelles § Similaire à une classe abstraite sans a"ribut § Comportement de la classe • Vocabulaire : § Une classe implémente une interface • Interfaces mulNples § AlternaNve à l’héritage mulNple ! 66 I C
  67. 67. 67 <<interface>> FloDant + floDer() + avancer() Véhicule + avancer() étend étend implémente pas de conflit • Complémentarité de l'héritage simple et interfaces mulNples § Hériter du concept primordial § Implémenter des interfaces
  68. 68. 68 Radar Avion Interface Détecteur Interface MachineVolante • SoluNon ? § Besoins du logiciel § Culture du concepteur
  69. 69. ComposiNon / AgrégaNon • ModélisaNon de la relaNon « est composé de » § ComposiNon, appartenance, groupage, « Has A » • ComposiNon § Les consNtuants disparaissent avec le composé • AgrégaNon § Les composants survivent à l'agrégat • ModélisaNon des conteneurs • NoNon de cardinalité § Simple / mulNple 69
  70. 70. 70 Objet agrégé Moteur Chassis Roue Voiture 4 1 1 1 1 1 Cardinalités : Une voiture agrège quatre roues Agrégateur
  71. 71. 71 AlternaNve à l’héritage mulNple ? 1 1 1 1 1 1 1 1
  72. 72. 72 AssociaNon • Modélise des concepts assez flous § Uses A § Est en associaNon avec § Communique avec • CaractérisNques § Habituellement nommée (auto documentaNon) § Sens § Cardinalités : 1 .. 4 • Souvent difficile à différencier de l’agrégaNon § Concepts voisins § Même implémentaNon
  73. 73. 73 ZOO – V1 Zoo Cage Gardien Animal 1 * 1 * 1 * * * nourrit 1 * habite * ne"oie *
  74. 74. 74 ZOO – V2 Zoo Cage Gardien Animal 1 * 1 * * * nourrit 1 * * ne"oie *
  75. 75. 90 80 70 60 généricité, excepNons opérateurs classes base Simula Pascal Algol C Objec(ve C Smalltalk Eiffel Delphi Ada Java C++ Quelques langages… C#
  76. 76. Visibilité des a"ributs et des méthodes en UML ? + public : tout le monde § Méthodes de l'interface publique -­‐ privé : classe seulement § AKributs § Méthodes privées # protégé § Privé pour l'extérieur -­‐ AKributs § Transmis par héritage § NoNon dépendante du langage ~ package 76
  77. 77. Fourmi ZZ ? 77 Fourmiliere Fourmi -­‐energie : unsigned int -­‐id : unsigned int -­‐energieMax : unsigned int = 10 +travailler() +manger(entrée quantite : unsigned int) Reine Ouvriere +nourrirFourmi(entrée inFourmi : Fourmi &) 1 * * *

×