recap final Flashcards
Un contrat protège les deux parties
Protège le client (dans ce cas ci vous mêmes)
o
Spécifie quelles sont ses obligations
o
En retour, est assuré d’un certain résultat
Protège le fournisseur (sous contractant)
o
Spécifie le minimum requis (de la part du client):
le fournisseur ne peut être tenu responsable
d’avoir manqué à des engagements ne figurant
pas dans le contrat.
La spécification d’un contrat
Spécification d’une interface
peut être vue comme un contrat entre un client (l’utilisateur du
composant/classe) et un fournisseur (le composant/
Le contrat dit ce qui doit être rencontré par le client
pour pouvoir appeler une opération de l’interface :
précondition
Le contrat dit aussi ce qui doit être réalisé par le fournisseur
ce qui est garanti au client
pour rencontrer ce qui est prévu par l’opération
postcondition
Les assertions : le contrat du logiciel
Mécanismes pour exprimer ces conditions :
assertions
préconditions
postconditions :
assertions s’appliquant à des méthodes en particulier,
invariants de classe :
assertions s’appliquant à toutes les méthodes d’une classe en
tout temps.
Une spécification plus complète d’une
opération offerte par un composant
deviendrait:
le nom de l’opération
o
le nombre, le type et l’ordre des paramètres
o
les préconditions
o
les postconditions
o
le type de retour.
Invariant de classe
Autre type d’assertion
o
représente l’ensemble des conditions logiques devant
être respectées pour assurer un comportement correct
d’une classe.
Immédiatement après la création d’un objet de
cette classe,
l’invariant doit être respecté et préservé tout au
long de la vie de l’objet.
Les MACROs pour le contrat
“fonction” définie par un #
Remplacement textuel, fait par le
préprocesseur.
Dans le fichier ContratException.h ,
1.
Définition de ces classes
2.
2.+ définition des MACROs suivantes:
PRECONDITION(test);
POSTCONDITION(test);
ASSERTION(test);
INVARIANT(test);
INVARIANTS();
Regardons ContratException.h
mise en oeuvre test unitaire
Doit être structuré
Doit être répétable
i.e. on doit pouvoir le faire exécuter le plus
souvent possible.
Doit fournir un rapport d’exécution extrêmement
simple (ok, pas
résultat d’une assertion
success (test réussi),
nonfatal failure (test
fatal failure (test échoué et arrête la
Construction et destruction :
Ordre d’appel
Construction des objets de la hiérarchie
o
de la classe de base tout en haut jusqu’à la
classe dérivée
Destruction des objets de la hiérarchie
o
de la classe dérivée jusqu’à la classe de base
Visibilités :
o
Privée : Accès interne de la classe.
o
Publique : Accès à tous les utilisateurs
o
Protégée : Accès aux héritiers
Les méthodes d’une classe ont
toujours accès aux attributs de la
classe, peu importe la visibilité
les données privées ne sont manipulables que par les méthodes
de la classe à laquelle les données appartiennent.
L’héritage ne donne pas d’accès privilégié pour la visibilité privée
Ajout de méthodes
Triangle qui est une classe dérivée de Polygone (
o
a immédiatement accès à cette nouvelle fonctionnalité,
Triangle2 qui utilise Polygone (
o
doit être ajoutée manuellement dans la classe Triangle2
Résultat intéressant d’un point de vue de gestion du code.
tout héritier de la classe Polygone a accès à ses méthodes
qu’elles soient écrites maintenant ou dans le futur
Remplacer, hériter, augmenter …
Une classe dérivée D peut décider de
prendre action sur une méthode m() de la
classe de base B:
La classe dérivée remplace la méthode
B::m() par D::m() en implantant un
algorithme différent.
La classe dérivée hérite de B::m() sans
changement.
La classe dérivée augmente la méthode
B::m() par une méthode D::m() qui appelle
d’abord B::m() avant de faire d’autre tâches.
En C++, trois formes :
Polymorphisme ad hoc :
Surcharge de m é thode(d é j à vu)
o
Polymorphisme param é trisable
Les templates
o
Polymorphisme pur
Le polymorphisme pur
Mé thodes virtuelles , alli é es à l’h é ritage:
o
permet de rendre les programmes extensibles par l’h é ritage
de comportements existants
ajout de comportements sp é cifiques au besoin.
Traitement d une famille de classe s une hi é rarchie de
fa ç on g é n é rique .
o
On n’a pas à identifier le type de la classe avec un switch
comme dans les langages non OO.
Traitement g é n é rique à partir de la classe de base
m
é thodes virtuelles .
o
à l’ é chelle d’une hi é rarchie de classes.
Signature des m
é thodes virtuelles
Une fonction virtuelle doit avoir la même signature
et même type de retour dans toutes la hi é rarchie.
Une fois qu’une fonction a é t é d é clar é e virtuelle,
elle le demeure dans toute la hi é rarchie à partir de
ce point
Méthodes virtuelles
Seule une fonction membre peut être virtuelle
Un constructeur ne peut être virtuel
Un destructeur peut être virtuel
Classes abstraites ou concr
è tes
En g é n é ral :
o
Cr é ation d une classe => cr é er des instances
Ce n’est pas toujours le cas…
Si cr é ation d une classe abstraite ,
Pas de cr é ation d’instance de cette classe.
Exemple :
on peut se servir d’une telle classe pour regrouper des concepts sous
une classe th é orique .
Bien plus que la th é orie
imposer une interface g é n é rale que toutes les classes h é riti è res
devront r é implanter
En C++, ¸ pour cr é er une classe purement abstraite
au moins une de ses m é thodes d é clar é es purement virtuelle.
trois grandes zones de mémoire:
Zone de la pile d’appel
*
Zone d’adressage statique
*
Zone d’allocation dynamique sur le monceau
*
Zone d’allocation dynamique
Les deux premières zones ont leur utilité
o
demeurent insuffisantes pour la plupart des
programmes sérieux.
dans un programme, on ne peut
o
estimer la quantité de mémoire nécessaire
o
prévoir à quel moment celle ci sera nécessaire.
o
réserver une très grande partie de la mémoire
simplement parce qu’on prévoit en avoir besoin.
utiliser l’allocation dynamique pour obtenir
et libérer de la mémoire lorsqu’on en a
vraiment besoin.
pour allouer de la mémoire dynamiquement,
opérateur new
On doit absolument récupérer l’espace alloué par le new
sinon on laisse ce qu’on appelle des déchets ( memory leaks
